I’m fully aware of the major differences between poll() and select():
select()only supports a fixed amount of file descriptorsselect()is supposedly supported on more systemspoll()allows slightly more fine-grained control of event typespoll()implementations may differ in certain details
However, they both accomplish the same task in roughly the same way. So:
Shall we use poll() or select()?
EDIT: I might add that I’m not interested in epoll() since portability is of concern to me. Furthermore, libev(ent) is not an option either, since I’m asking this question because I’m writing my own replacement library for libev(ent).
All remotely modern systems have
poll, and it’s a greatly superior interface toselect/pselectin almost all ways:pollallows more fine-grained detection of status thanselect.polldoes not have limits on the max file descriptor you can use (and more importantly, does not have critical vulnerabilities when you fail to check for file descriptors past theFD_SETSIZElimit).The only disadvantages I can think of to using
pollare that:pselect,pollcannot atomically unmask/mask signals, so you can’t use it for waiting for a set of events that includes both file descriptor activity and signals unless you resort to the self-pipe trick.pollonly has millisecond resolution for the wait timeout, rather than microsecond (select) or nanosecond (pselect).Certainly portability of
pollis not a consideration anymore. Any system old enough to lackpollis full of so many vulnerabilities it should not be connected to a network.In summary, unless you have very special needs (tiny timeout intervals, nasty signal interactions, scaling to millions of persistent connections, etc.) I would simply use
polland be done with it. As others have mentioned,libeventis also an option, but it’s not clean/safe code (its use ofselectactually invokes dangerous UB trying to workaround the limitations ofselect!) and I find code that useslibeventis generally a lot more unnecessarily complicated than code that simply usespolldirectly.