Messages in this thread | | | Date | Fri, 19 Jun 1998 06:11:38 -0700 | From | "David S. Miller" <> | Subject | Re: Thread implementations... |
| |
Date: Fri, 19 Jun 1998 06:11:10 -0700 (PDT) From: Alex Belits <abelits@phobos.illtel.denver.co.us>
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.
Later, David S. Miller davem@dm.cobaltmicro.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |