hjstein@bloomberg.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?
The former requires threads -- you need multiple execution contexts if
you're going to take advantage of having multiple processors, though
typically what one does is just allocate one thread per processor and
that's sufficient -- each thread runs the event loop on one
processor. This is of more interest for things like event driven web
servers than for things like GUIs where the compute requirements are
usually modest. (Of course, scsh's threads are implemented entirely in
userland and thus can't help here, but never mind that.)
The second point you make, the GUI case, typically DOES NOT require
threads -- the answer is "you just don't block". Lets say, for
example, that you are going to block pending a reply from your DNS
server. You don't -- instead you restructure the code so that the
arrival of the reply packet to the DNS query becomes an event instead,
and while you're awaiting the reply the event loop continues. If the
user wants to interact while you're waiting to resolve the hostname,
they just do. By never blocking on I/O, you eliminate virtually all
the cause for the GUI to freeze. It is fairly rare that a program like
this actually needs to go off and crunch CPU for five minutes. In
those rare instances, you can spawn a thread or (in many cases) use a
work proc. However, in typical applications like, say, an editor or a
web browser or what have you, you almost NEVER need a thread. I've
written a lot of event driven programs and I can only think of a
couple of instances where I started a new thread or the equivalent in
a GUI sort of situation.
In the web server case, of course, one thread per connection is
absolutely unscalable. If you want to handle ten thousand connections
simultaneously (and there is no rational reason you shouldn't be able
to -- many servers CAN do that for static content), the only paradigms
that work are event driven, not thread driven. It is easy to handle
ten thousand TCP connections on a modestly scaled modern machine with
events, and I have yet to see the thread implementation that didn't
start to have trouble with at most a few hundred threads, let alone
ten thousand.
In any case, however, I'm not suggesting threads be banished. I'm
merely suggested that it is not pleasant for those of us who want to
do event driven programs not to be able to do so, and the lack of a
select call makes it impossible to implement an event loop.
Indeed, it would be neat to hide the event mechanism from the user, so
that the underlying mechanism (select, poll, or modern more efficient
calls like the /dev/poll device or kqueues) could be hidden from the
programmer. However, one must have *something*.
--
Perry E. Metzger perry@piermont.com
--
"Ask not what your country can force other people to do for you..."
|