3 ms·

They said that back in old days (90s) there was no good scalable TCP implementation which could handle many simultaneous connections properly. I think that's t

• wahern 10y ago
  select doesn't have such an inherent limit. The limit is an artifact of the way the fd_set structure and macros are defined and implemented. Most unix-like kernels, including Linux, will accept a much larger fd_set. The userspace libraries (including glibc) even often permit you to redefine FD_SETSIZE at compile time, which makes it even easier. That can cause problems when sharing fd_sets between different libraries, though, so isn't a good idea. IME once you get past an FD_SETSIZE of 8192 the overhead of preparing 3KB of data on every single select call begins to show appreciable CPU load. CPUs are fast enough that you'll rarely get more than a handful of pending events per call even with thousands of active connections, so the cost isn't amortized well. Nonetheless, if you use epoll without actually making use of and benefitting from persistent events (as some naive applications do, including a much-touted "high-performance" platform), select can even be faster than epoll under load. Under load, a naive application which resets events on a descriptor every time it processes that descriptor is pushing much more data through syscalls than select would.