Messages in this thread | | | From | Snow Cat <> | Subject | Re: Threads question | Date | Sat, 26 Apr 1997 10:49:23 -0700 (PDT) |
| |
Michael Nelson once wrote: > > On Fri, 25 Apr 1997, Todd Graham Lewis wrote: > > > > 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. > > I don't agree. > > A much more efficient solution would be to setup a small pool of threads > to handle the incoming network I/O and work-related tasks which can grow > and shrink as needed based on average work load or a similar algorithm. >
Sure, but is there a reason that the code to multiplex a pool of threads between tasks shouldn't be in a library? :) If 4K stack/thread overhead is too much, you can either use a regular malloc()ed chunk for stack or consider that an IRC server+kernel are going to use some memory for each connection anyway.
I don't see why an application with 1000 threads that are blocked in network I/O most of the time has to be less efficient than one using select(). At the same time, in a threaded application it's easier to start processing a second network request when the first one has blocked for some other reason and to include background tasks written by other people.
-- _. _ . (_ ,_ _ , . / ` _ _L | Email: Oleg Kibirev <snowcat@netgate.net> ._)| U(_)\/\/ \_,(_L/L | http://ng.netgate.net/~snowcat/ ------------------------'
| |