>>>>> "Perry" == Perry E Metzger <firstname.lastname@example.org> writes:
Perry> email@example.com (Harvey J. Stein) writes:
>> I'm a little confused. One of the points of using threads is to allow
>> simultaneous paths of execution, so as, for example, to improve
>> performance on multiprocessor machines, or to avoid having a GUI hang
>> while the application performs a time-consuming activity.
>> How are these accomplished without threads?
Perry> The second point you make, the GUI case, typically DOES NOT require
Perry> threads -- the answer is "you just don't block". Lets say, for
Perry> example, that you are going to block pending a reply from your DNS
Perry> server. You don't -- instead you restructure the code so that the
Perry> arrival of the reply packet to the DNS query becomes an event instead,
Perry> and while you're awaiting the reply the event loop continues. If the
Perry> user wants to interact while you're waiting to resolve the hostname,
Perry> they just do. By never blocking on I/O, you eliminate virtually all
Perry> the cause for the GUI to freeze.
The client-of-multiple-servers case is indeed one of the primary
applications of SELECT. The DNS code in SUnet needs it.
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.
Sure, the average word processor does nothing but handling
events---it's not concurrent in nature. But many interactive
applications *are* concurrent in nature: things need to happen without
I/O events occurring. For these applications, event-driven
programming is a major pain. And, once again, concurrency trivially
subsumes event-based models.
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.)
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?
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla