Well, select (and poll) do have inherent limitations. For each call to select the kernel must check all specified descriptors to see if they are ready. Performance of that depends on the number of descriptors. Also, in a busy application select can be called very often. I think it's fair to call it 'polling'.
With epoll and other similar mechanisms, it's only necessary to register all 'interesting' descriptors once, and then, when IO happens on some descriptor, the kernel checks if the application is interested in it. Therefore, performance is determined by the number of IO events.
If we have a ton of descriptors, but, at any given time, IO actually happens only on some small percent of them, epoll will vastly outperform select, because, yes, it does less 'polling'.
Yeah, when I use select, it doesn't burn CPU when waiting.
But do you have 10k concurrent connections :) | [reply]
[d/l]
[select] |
| [reply] |
