Below comments are from Marc Lehmann, developer of the libev event library.
Can anyone comment on if this is still accurate?
Thanks,
Aaron
//////////////////////////////////////////////////////////////////
The epoll mechanism deserves honorable mention as the
most misdesigned of the more advanced event
mechanisms: mere annoyances include silently dropping
file descriptors, requiring a system call per
change per file descriptor (and unnecessary guessing of
parameters), problems with dup, returning
before the timeout value, resulting in additional
iterations (and only giving 5ms accuracy while
select on the same platform gives 0.1ms) and so on. The
biggest issue is fork races, however - if a
program forks then both parent and child process have
to recreate the epoll set, which can take
considerable time (one syscall per file descriptor) and
is of course hard to detect.
Epoll is also notoriously buggy - embedding epoll fds
should work, but of course doesn’t, and epoll
just loves to report events for totally different file
descriptors (even already closed ones, so one
cannot even remove them from the set) than registered
in the set (especially on SMP systems). Libev
tries to counter these spurious notifications by
employing an additional generation counter and
comparing that against the events to filter out
spurious ones, recreating the set when required. Last
not least, it also refuses to work with some file
descriptors which work perfectly fine with "select"
(files, many character devices...).
Epoll is truly the train wreck analog among event poll
mechanisms, a frankenpoll, cobbled together in
a hurry, no thought to design or interaction with others.
