Re: Threads question

Dean Gaudet (dgaudet-list-linux-kernel@arctic.org)
Fri, 25 Apr 1997 18:26:04 -0700 (PDT)

It is a common mistake for people considering multithreading things like
IRCs and MUDs to reason that each connection should be a thread. I mean
it's an obvious way to break up the tasks amongst threads. However it's
far better, performance-wise, to have a queue of events which are
processed by a dynamic number of worker threads. Thus you only require as
many threads as you have work to do. Tuning that number is a matter of
work, and depends on how you want the whole thing to function.

If you just want to take advantage of SMP and other parallelisms it's also
possible to run multiple "heavyweight" processes as a cluster. (Consider
Apache.)

Dean

On Fri, 25 Apr 1997, Todd Graham Lewis wrote:

> On Fri, 25 Apr 1997, David S. Miller wrote:
>
> > Threading is good, use the kernel facilities, and don't over do it.
> > People who think they need thousands of threads really don't, they
> > just need to heavily rethink their design.
>
> Disclaimer: I am not an expert systems programmer, and David is.
>
> Still, though, there are legitimate applications wherein having multiple
> thousands of threads necessary. The most active IRC server on the net,
> from what I understand, is a FreeBSD Pentium which can accept ~1500 (this
> is from memory) connections.
>
> IRCD is a single-threaded application; threading it would be a very nice
> option (allows use of SMP facilities, etc.) If it is going to destroy its
> host machine by threading, however, then people aren't going to do it, or
> they're only going to do it on platforms which allow them to do it.
>
> A combo (clone<->lib) threading approach lets you do these sorts of things
> easily. Telling the IRC designers "You shouldn't support more than 1000
> connections per server" is kind of unrealistic, isn't it?
>
> --
> Todd Graham Lewis MindSpring Enterprises tlewis@mindspring.com
>
>