Don G wrote:
Without threads the network would have a capacity limit of FD_SETSIZE, but even with threads the system has a limit. I found it trying to stress test my thread pool solution<g>. So, if the capacity limit of FD_SETSIZE is acceptable for the application, and threads are to be avoided, then I can see their argument.
FD_SETSIZE only applies to select, and nobody uses select except in "quick and dirty" servers (as I did recently). 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). Of course, if the threaded model can be demonstrated to achieve comparable performance, there would be no need to complicate the interface with poll().