[IiydAbITMvJkqKf]

NEVER use select(). It's like gets() - an API that should never be called in new code. poll is the standardized alternative (epoll/kqueue are more performant with large numbers of fds, but are os-dependent).

The biggest problem with select() is that it will corrupt your stack if you use it with an fd with a value >= 1024. Since you can't easily control fd values, you must assume that calling select() is UB unless explicitly proven otherwise. There are also performance problems due to having to set up the sets before each call, but these are minor in comparison.

[kragen]

You can easily control fd values, and attackers can't control them, so even if you're using fd_set, it's not like gets(). You can use select() safely by dynamically allocating your bitvectors, assuming you're using a sensible kernel instead of one that only cares about standards-compliance.

Or you could just not have thousands of open files in a single process, which is the way every single Unix program worked for the first 25 years of Unix. I have 269 processes running on this machine right now and none of them is using a file descriptor greater than 255. Even Firefox is only using up to fd 75. The worst offender is gnome-terminal, using fds up to 226, and its children. Having thousands of simultaneously open files is a useful way to structure a few specialized programs like chat servers and load balancers, but it's not something most programs need to worry about.

Of course in a library the situation is different, but you probably shouldn't be calling poll() or select() in a library unless it's something like libevent, libev, or libuv, because you can't use two such libraries in the same program unless you're willing to suffer multithreading.