firstname.lastname@example.org (Michael Sperber [Mr. Preprocessor])
> Perry> It is fairly rare that a program like
> Perry> this actually needs to go off and crunch CPU for five minutes. In
> Perry> those rare instances, you can spawn a thread or (in many cases) use a
> Perry> work proc. However, in typical applications like, say, an editor or a
> Perry> web browser or what have you, you almost NEVER need a thread.
> I invite you to look at the structure of Mozilla these days. A lot of
> the mess it's in currently is exactly because of this.
Mozilla is not a mess because of the event driven code. It is a mess
because the people writing it did not know how to structure their
work. I've seen other event managed systems that were not messy.
> Perry> In the web server case, of course, one thread per connection is
> Perry> absolutely unscalable. If you want to handle ten thousand connections
> Perry> simultaneously (and there is no rational reason you shouldn't be able
> Perry> to -- many servers CAN do that for static content), the only paradigms
> Perry> that work are event driven, not thread driven.
> Why wouldn't this scale in scsh? (There are a number of reasons
> currently, but none of them are related to threads.)
Well, it doesn't scale in machine language^W^W C, and although I've
heard many claims that you can compile Scheme to be as efficient as C,
I've never seen the claim that you can be orders of magnitude better
than C. You are ultimately constrained by the reality of threads
systems. Even the best aren't that great.
As I've noted, there are a lot of good academic papers with nice
metrics showing the performance of lots of kinds of web servers, and
the thread driven ones die after very few connections, while the event
driven ones just keep chugging along. I'll happily forward references
-- Niels Provos' papers are the ones I'd recommend starting with, but
there are others.
This isn't a C or Scheme issue. Its a simple issue of how much state
you're flinging around and how expensive a thread switch is compared
to a procedure call. Getting threads to be as cheap as procedure calls
is just not possible, and not for want of decades of trying.
Scheme is a lovely language, and I'd rather use it for doing systems
programming than dealing with C. I just don't believe it magically
solves the threads problem.
> Perry> In any case, however, I'm not suggesting threads be banished. I'm
> Perry> merely suggested that it is not pleasant for those of us who want to
> Perry> do event driven programs not to be able to do so, and the lack of a
> Perry> select call makes it impossible to implement an event loop.
> I don't get your point. I said we'll put SELECT back in. What
> exactly do you want?
Nothing. I'm happy since you're putting the functionality back in. At
this point I'm just disputing your claims about the superiority of
threads vs. events, especially for heavily multiplexed i/o.
Perry E. Metzger email@example.com
"Ask not what your country can force other people to do for you..."