I want to make clear, by the way, that I'm not "demanding anything" --
you've said that some sort of select-like mechanism is on its way
back, so I'm happy. I'm just disputing a few claims that have been
made about event driven vs. thread driven systems.
> Perry> Second of all, the research on the topic at this point is pretty
> Perry> conclusive -- implementing large multi-client servers on event driven
> Perry> platforms scales well, and on thread based systems scales quite
> Perry> poorly.
>
> This isn't the case in scsh---here, threads are much more light-weight
> than in the systems you cite.
The research that's been done over the years (I'll provide a
bibliography if you want) tends to indicate that thread expense is an
operating system issue far more than a language issue. People dealing
with thread systems often start out by thinking they can make threads
really cheap by doing everything in userland without kernel
assists. Handling the threads there is potentially less expensive, but
has serious problems when it comes to properly implementing thread
semantics. Things like poor support in userland for preemption and
blocking system calls make userland thread libraries nearly impossible
to get right, not that there haven't been large numbers of
tries. There's another issue, of course, which is that without kernel
assists, you can't take advantage of multiple processors AT ALL.
Even the lightest weight kernel assisted systems, however, like
scheduler activation based systems, consume lots more resources than
you would like, and take much more time than you would like. They have
to do system calls and upcalls for every thread switch, and system
calls are far more expensive than you would like. You also end up,
pretty much regardless of what you might want, having to store the
full execution context for each of those threads, which is a whole lot
more than, say, a half dozen state variables for each connection in an
event driven server.
If you think about it for a minute, none of this should be very
surprising.
(If it is surprising, I'll happily start spitting paper references
out. The literature on this stuff is quite rich.)
However, you claim that I'm wrong, and that the threads in scsh are
very light weight -- far more light weight, we presume, than C
pthreads on an SA system like Solaris or something similar. Okay,
prove it. I can run ten thousand client connections in several web
servers I know out there using events. Show me ten thousand threads
really functioning and doing I/O in scsh. I am prepared to see a
demonstration.
Handling ten thousand fd's with select to drive an event loop is of
course impossible -- you end up needing /dev/poll or kqueue
abstractions -- but that is a detail. I've yet to see a system spawn
more than a few hundred threads and still do useful work, but event
driven systems can.
> Perry> Third, let me note that event driven is the natural style in which to
> Perry> write GUI driven applications, and that virtually all GUI toolkits use
> Perry> the event driven style for that reason. If you want to build GUIs, you
> Perry> need events.
>
> No, you don't. Actually, writing reactive concurrent applications in
> an event-driven style is a major pain.
Having written them in an event driven style and in a thread driven
style, I'll tell you that I'll take event driven any day. I never
understood why it was so hard to express the semantics of what I
wanted to happen until someone slapped me upside the head and showed
me event driven programming.
Your mileage may vary, of course. Different people find different
systems "natural".
> Moreover, thread-based toolkits trivially subsume event-based toolkits.
Could you explain that more?
> Perry> Lastly, having written large multi-client servers in the past, let me
> Perry> note that event driven systems are *much* easier to write correctly
> Perry> once you are used to the style.
>
> Lastly, having written large multi-client servers in the past, let me
> note that thread-based systems are *much* easier to write correctly
> once you are used to the style.
Well, of course, this could just degenerate into a pissing
match. "Ease" is difficult to measure and we could both just cite
systems we'd been involved with. However, performance limits are easy
to measure. Could you give me the example of the system capable of
handling ten thousand threads? Ten thousand event driven clients I've
seen -- I've never heard tell of a system that could manage more than
a few hundred threads.
> Perry> What is a CML framework? (C=? ML=the language ML?)
>
> Yes. CML stands for "Concurrent ML." It's a substrate for
> message-based concurrent programming in ML. It translates
> straightforwardly into Scheme.
>
> Normally, I'd cite John Reppy's homepage as a source for material on
> CML, but that seems to be temporarily offline. There's also
>
> @Book{Reppy1999,
> author = {John H. Reppy},
> title = {Concurrent Programming in {ML}},
> publisher = {Cambridge University Press},
> year = 1999
> }
Interesting. I'm quite ignorant of it so I suppose I have some reading
to do.
Perry
--
Perry E. Metzger perry@piermont.com
--
"Ask not what your country can force other people to do for you..."
|