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 detailsHowever, 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)
.
poll offers somewhat more flavors of events to wait for, and to receive, although for most common networked cases they don't add a lot of value. Different timeout values. poll takes milliseconds, select takes a struct timeval pointer that offers microsecond resolution.
The select() call has you create three bitmasks to mark which sockets and file descriptors you want to watch for reading, writing, and errors, and then the operating system marks which ones in fact have had some kind of activity; poll() has you create a list of descriptor IDs, and the operating system marks each of ...
poll( ) is more efficient for large-valued file descriptors. Imagine watching a single file descriptor with the value 900 via select()—the kernel would have to check each bit of each passed-in set, up to the 900th bit.
The select() and poll() methods are used for multiplexing network sockets. Find out how to use these functions, and learn about their limitations. The select() and poll() methods can be a powerful tool when you're multiplexing network sockets.
All remotely modern systems have poll
, and it's a greatly superior interface to select
/pselect
in almost all ways:
poll
allows more fine-grained detection of status than select
.poll
does 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 the FD_SETSIZE
limit).The only disadvantages I can think of to using poll
are that:
pselect
, poll
cannot 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.poll
only has millisecond resolution for the wait timeout, rather than microsecond (select
) or nanosecond (pselect
).Certainly portability of poll
is not a consideration anymore. Any system old enough to lack poll
is 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 poll
and be done with it. As others have mentioned, libevent
is also an option, but it's not clean/safe code (its use of select
actually invokes dangerous UB trying to workaround the limitations of select
!) and I find code that uses libevent
is generally a lot more unnecessarily complicated than code that simply uses poll
directly.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With