[lkml]   [1998]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Thread implementations...
On Fri, 19 Jun 1998, Richard Gooch wrote:

> David S. Miller writes:
> > Date: Thu, 18 Jun 1998 11:37:28 -0700 (PDT)
> > From: Dean Gaudet <>
> [...]
> > Unix multiplexing facilities -- select and poll -- are wake-all
> > primitives. When something happens, everything waiting is awakened
> > and immediately starts fighting for something to do. What a waste.
> > They make a lot of sense for processes though. On NT completion
> > ports provide wake-one semantics... which are perfect for threads.
> >
> > Yes, this does in fact suck. However, the path to go down is not to
> > expect the way select/poll work to change, rather look at other
> > existing facilities or invent new ones which solve this problem.
> > Too much user code exists which depends upon the wake-all semantics,
> > so the only person to blame is whoever designed the behaviors of these
> > unix operations to begin with ;-)
> On the other hand you could say that the UNIX semantics are fine and
> are quite scalable, provided you use them sensibly. Some of these
> "problems" are due to applications not being properly thought out in
> the first place.

#ifdef SARCASM

"Thundering Herd Problem II", with all original cast... ;-) This time it's
not accept(), but poll(), and the whole thing is multithreaded...


> If for example you have N threads each polling a
> chunk of FDs, things can run well, provided you don't have *each*
> thread polling *all* FDs. Of course, you want to use poll(2) rather
> than select(2), but other than that the point stands.

Can anyone provide a clear explanation, what is the benefit of doing
that in multiple threads vs. having one thread polling everything, if the
response on fd status change takes negligible time for the thread/process
that is polling them (other processes complete the operation while polling
comtinues)? I have a server that uses separate process mostly for polling,
however I'm not sure what poll()/select() scalability problems it may
encounter if used with huge fd number.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

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