Hi Peter,

FD_SETSIZE only applies to select, and nobody uses select except in "quick and dirty" servers (as I did recently).

Sadly, select is by far the most portable solution. On Windows, it is the only solution for 9x/Me. We can and should write more efficient impls for platforms that support poll() or epoll() or kqueue, etc..

The idea of an explicit poll() call is to allow the implementation to use a single-threaded dispatch mechanism (select/epoll/kqueue), if one is available. Without poll() you are forced to use worker thread(s) and a callback queue to support a single-threaded application, and this can be considerably less efficient than epoll/kqueue (or select in the < FD_SETSIZE case) (in theory).

Yes, indeed. Though I may be missing something in your idea about net::poll(). How would it avoid a queue?

Of course, if the threaded model can be demonstrated to achieve comparable performance, there would be no need to complicate the interface with poll().

The "need" is performance and familiarity (IMO). If performance were taken out of the picture, it would be hard to argue for it. I don't know how the comparison would go which is why I was writing some stuff to try it out and get some measurements. Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com