poll vs. epoll insight [duplicate]

Question

Are there some simple rules of thumb when to use poll vs. epoll in a low-latency environment? epoll should have higher overhead if only few of file-descriptors is monitored. Please, give some insight, answers "check it yourself" put elsewhere.

Answer 1

Always use poll unless all of the following are satisfied:

1. You can ensure you're on a (Linux) system that has epoll or you provide a fallback for systems that don't.
2. You have a huge number of file descriptors active (at least 1000-10000).
3. The set of file descriptors you're working with is stable over a long time period (adding/removing file descriptors from the epoll list is just as expensive as a poll operation, since it requires entering/leaving kernelspace).

Answer 2

First of all, poll(2) is only level-triggered, but epoll(4) can be used as either edge- or level-triggered interface.

Now complexity: poll complexity regarding number of watched descriptors (fds) is O(n) as it scans all the fds every time when a 'ready' event occurs, epoll is basically O(1) as it doesn't do the linear scan over all the watched descriptors.

In terms of portability - as epoll is Linux-specific I would suggest checking out libev and libevent libraries. Also, check out Dan Kegel's excellent writeup: "The C10K problem".