More poll()/epoll fun

I generally assume that select(), poll(), and epoll are interfaces to the same thing. Sure, they have different input flags (notably, epoll suppports edge-triggered), but I expect that each is a superset of the previous, with a better interface for large numbers of fds.

Of course, though, there are quirks. poll() and epoll behave very differently if you’ve got some fds to regular files in the mix. I spent awhile chasing this, because people all over the web claim that poll() doesn’t work on regular files. It actually does; this bug has a decent description.

If you look at fs/select.c, line 723 to 731, you notice that in case f_op->poll is not provided by the device, DEFAULT_POLLMASK is used as returned mask, where DEFAULT_POLLMASK is defined as (POLLIN | POLLOUT | POLLRDNORM | POLLWRNORM).

Later on, this DEFAULT_POLLMASK is masked with your mask, which returns POLLIN, even though no test have been really performed with the device, since a file device does not provide an f_op->poll() function.

Epoll will fail you explicitly, while poll/select will not. but nothing meaningful is returned from poll/select on file system files.

Unfortunately, the poll() behavior is probably what you want (a regular file is always readable, because there’s either more data or you’re at EOF). If you want to get the same behavior in an epoll loop, you’ve got to keep a separate list of regular fds that failed epoll_ctl(EPOLL_CTL_ADD) with EPERM, and treat them as always readable/writable within your code. Linux should really add an EPOLL_SHUT_UP_I_KNOW_ITS_JUST_A_FILE that emulates the poll() behavior and saves implementors the complexity.