In defense of epoll

In defense of epoll

(+1, Insightful) - nice explanation of what bloat actually is in this context and why it must be avoided even when it doesn't directly affect the object code. But -

I for one thought epoll() should have been held back a release, to see if an overall better API could be conceived.

I disagree, in this instance. For one thing, epoll() isn't exactly new. A port of the Solaris /dev/poll first appeared somewhere in early 2.3.x, if I remember correctly. Linus shot it down on the spot - "we don't need no stinking device file", as it were - and thus the syscall approach was born. So this isn't someone's last-minute feature-freeze brainfart (like sendfile(), which was conceived, implemented and integrated all within about a week, just before 2.2.0) - it's been kicking around for quite awhile.

For another thing, note that the epoll stuff is itself a second system, quite aside from the /dev/poll business. It is already a redesign of the classic select() and poll() interfaces. In fact, you can go further: midway through 2.1.x, Richard Gooch (I think) introduced poll() as an independent syscall; previously it had been emulated using select(), which is not as efficient in the case of a sparse fd set.

So to summarise, epoll is a reimplementation of poll() which is a reimplementation of the select-emulation-based poll(), and people have been thinking about this interface for at least 2 years now.

I for one rather like the epoll API as described by Jon on these pages. It seems to map rather well to the familiar FD_ZERO(), FD_SET(), etc. used with select() ... so converting code to use epoll should not be too hard. My only question is whether it would have been worthwhile to specify a way to pass a whole array of fd's rather than just a single fd per syscall, but I suspect it doesn't matter much - syscalls are cheap in Linux, and you only have to set up your epoll structure once (that being kind of the whole point!).