File Descriptor Limits
No new code should be using select().  Using it assumes the execution environment keeps all file descriptor values within FD_SETSIZE.I've personally had to debug and fix crashes due to this assumption at multiple jobs.Back at Hostway decades ago we had Apache+SSL instances randomly crashing which turned out to be due to something opening /dev/random and using select() on the returned file descriptor in a .so.  This only happened when the machine had enough virtual hosts to exceed FD_SETSIZE on the spurious open of /dev/random.At Bizanga we had random crashes in their "carrier grade mail server" software, which would link in proprietary modules from vendors like Symantec for realtime virus scanning before even accepting messages for delivery.  This stuff ran in-process for performance reasons, just in separate threads.  Being "carrier grade" meant thousands of concurrent connections -> thousands of open files.  Those vendor-provided plugins would phone home behind the scenes for virus db updates.  Turned out they were using select() on the socket connected for the update, if there were enough active sessions at the time, the socket's value would exceed FD_SETSIZE and boom: segfault.People tend to forget that it's the value of the fds you pass to select() which can't exceed FD_SETSIZE, not just the quantity of file descriptors.  It could be just one file descriptor, but if it's a high enough value exceeding FD_SETSIZE, it will segfault.  The value is used as an index into a fixed size array.I ended up making an execution wrapper @ Bizanga to launch everything with >FD_SETSIZE file descriptors already opened once I saw the vendor modules were linking select().  We found numerous crashes this way, without waiting for them to occur in production.