On 30/06/11 16:45, Alexander Clouter wrote:
Phil Mayers<p.mayers@imperial.ac.uk> wrote:
On that latter topic: I do wonder if we might start running into problems with fd_set size limitations now that "master" supports TCP sockets. Eduroam sites (e.g. us) using radius-over-TLS and DNS-based autodiscovery could, conceivably, have many tens of TCP connections open at any given time. But an epoll event core is probably pretty trivial, given that Alan has factored the existing loop cleanly.
epoll is for when you have 1000's of FD's...not less than 100. epoll is
I'll let JP reply for me: http://stackoverflow.com/questions/2032598/caveats-of-select-poll-vs-epoll-r... tl;dr - select has a microscopic advantage over epoll for very tiny numbers of FDs, but it's negligible in modern systems. epoll scales better and has far, far better worst-case performance, as well as handling many idle connections better. There's absolutely no discernible issue with using epoll over select in any app except a micro-benchmark designed to test syscall latency in the case with small numbers of FDs. So, I disagree completely ;o)