On Fri, 23 Dec 2005 10:17:00 -0000 (GMT) "christopher baus" <christopher@baus.net> wrote:
I do think that is probably a rare case though, especially on internet facing servers. Plus epoll allows edge triggering to prevent being re-notified of readiness events. But you do have a point here. I always just thought "epoll better" but now I see specific cases where that might not be true.
Maybe on WAN servers, but not on high performance LAN based servers. Ruunning a simple test on 100 file descriptors, here is what I get. poll() calls per second: 107906 select() calls per second: 104891 epoll() calls per second: 70923 Granted, it's not a huge difference, and other numbers of FDs show differing results (also, only selecting for 1 FD in epoll() shows lots better results, but you have to make more system calls as well. Anyway, my point is that there surely are use cases where a user would want control over which underlying implementation is used. The programmer should be allowed to determine which implementation is used under the hood, and should be able to use several different ones for several different uses. I do not see this as exposing implementation details to the detriment of encapsulation. On the contrary, it gives the user the ability to have finer control. You can still default it to whatever you want, and if the defaults are good enough, then fine.
The problem is it is really difficult to decide which will be better for most users. I could almost see the same app allowing both epoll and select with the same binary, but I'm not sure the complexity is worth it.
Why not? The complexity would be exposing some mechanism to specify the underlying implementation. It doesn't have to be the implementation itself, just some token representing an implementation. Without the ability to tell the library which implementation to use, this library is severely lacking.
I've read a few of Rene's and Chris's comments on configuring for epoll/select, and my feeling is that on Linux if epoll is there, use it. But it is also possible to test for the existence of epoll at run time so the same binary can run on 2.4 and 2.6 kernels.
That's fine, for default behavior, but I still argue that the programmer should be given the ability to specify the underlying implementation.
I don't know of any apps that purposefully choose to use select() in the presence of epoll(), if an epoll() implementation for the app is available. If anything most app developers have been scrambling to provide epoll() support.
I know of at least 2 ;-)