RE: Why use threads ( was: Alan Cox quote?)

["David Schwartz" <davids@webmaster.com>]

> On Wed, Jun 20, 2001 at 03:18:58PM -0700, David Schwartz wrote:

> > 	As I said, you don't want to use one thread for each
> > client. You use, say,
> > 10 threads for the 16,000 clients. That way, if an occasional client
> > ambushes a thread (say by reading a file off an NFS server or
> > by using some
> > infrequently used code that was swapped to a busy disk), your
> > server will
> > keep on humming.

> This same approach can easily be used by multiple processes.

	Theoretically, pretty much everything you can do with a thread pool
architecture can be done with a process pool architecture. Sharing file
descriptors can be much harder. Some thread architectures (notably pthreads)
go out of their way to make some things hard for thread pools (like try
implementing Samba, since all the threads share there uids). But this is
more about bad threading specifications and implementations than threading
itself.

> I don't see what is gained by using threads over processes for such an
> architecture.

	I'll flip this back at you and ask you what's gained by using processes
over threads. It's certainly more difficult to implement a process pool
architecture than a thread pool architecture. Theoretically, performance for
a thread pool architecture will be slightly better (on some architectures at
least) due to the identical vm views.

	With a process pool architecture, you might have more control over what you
share. But this doesn't actually gain you anything because as long as you
share more than a small amount, you still have to consider your entire
environment tainted if one execution vehicle goes out of control.

	I would be very interested in seeing, for example, a web server based on a
'process pool' design. Does anybody know of any?

	DS