lkml.org 
[lkml]   [1997]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Threads question
Date
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/
------------------------'

\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.063 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site