Re: Single-threading servers and select()

[David Burgess <dburgess@...>]

Remember that there are selects() friends devpoll/kqueue/poll (and others?).
In the real world I have found the select() overhead to be insignificant.
As someone (Mike I think) pointed out, if you are processing 1000's of
concurrent connections the socket APIs are probably not what you want.

I have found the critical issues(in my world) to be:
 - connection rates (how fast can you accept a connection).
 - bandwidth. 
 
In the server applications I have been involved with, select() (or
something like it)
has not been an issue. Managing bandwidth is an issue. Non-blocking / async IO
applications are simpler to code and debug and hence manage bandwidth.

High performance commercial web servers such as zeus are minimally threaded
and use non-blocking IO. The argument about non-blocking/single threaded versus
blocking/multithreaded is settled by Web server benchmarks.
Non-blocking wins the
benchmarks. Non-blocking scales.


DB