[lkml]   [1998]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Thread implementations...
   Date: Fri, 19 Jun 1998 06:11:10 -0700 (PDT)
From: Alex Belits <>

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.

I look at it this way.

If you can divide the total set of fd's logically into seperate
groups, one strictly to a particular thread. Do it this way.
The problem with one thread polling all fd's and passing event
notification to threads via some other mechanism has the problem that
this one thread becomes the bottle neck.

The problem, for one, with web etc. servers is the incoming connection
socket. If you could tell select/poll "hey, when a new conn comes in,
wake up one of us", poof this issue would be solved. However the
defined semantics for these interfaces says to wake everyone polling
on it up.

David S. Miller

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.113 / U:5.320 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site