Async IO on Linux: select, poll, and epoll

[luantranminh]

https://jvns.ca/blog/2017/06/03/async-io-on-linux--select--poll--and-epoll/

First way: select & poll

poll and select fundamentally use the same code. They both call a lot of the same functions. One thing that the book mentioned in particular is that poll returns a larger set of possible results for file descriptors like POLLRDNORM | POLLRDBAND | POLLIN | POLLHUP | POLLERR while select just tells you “there’s input / there’s output / there’s an error”.

select translates from poll’s more detailed results (like POLLWRBAND) into a general “you can write”

why don’t we use poll and select?

From the book:

On each call to select() or poll(), the kernel must check all of the specified file descriptors to see if they are ready. When monitoring a large number of file descriptors that are in a densely packed range, the timed required for this operation greatly outweights [the rest of the stuff they have to do]

what’s epoll?

The epoll group of system calls (epoll_create, epoll_ctl, epoll_wait) give the Linux kernel a list of file descriptors to track and ask for updates about activity on those file descriptors.

performance: select & poll vs epoll

In the book there’s a table comparing the performance for 100,000 monitoring operations:

Number of descriptors monitored (N)	poll() CPU time (seconds)	select() CPU time (seconds)	epoll CPU time (seconds)
10	0.61	0.73	0.41
100	2.9	3.0	0.42
1000	35	35	0.53
10000	990	930	0.66