Saturday, January 29, 2011

Why poll is not replaced with epoll?

Level-triggered epoll is very similar to poll. Why isn't poll just a wrapper for epoll on systems supporting the latter?

EDIT: I mean, are there any technical barriers against such decision? Implementing poll as epoll would dramatically boost performance of many network applications. There should be some technical issue that I fail to notice.

  • The semantics of poll() and epoll are different. If poll() informs you that a descriptor is readable, then you do some reading but do not read all the bytes available, and then pass that descriptor into poll() again, it will wake up immediately. AFAIK the same is not true of epoll.

    Also note that epoll descriptors are a limited resource. The manpage talks about epoll_create() failure conditions which AFAIK do not occurr with poll().

    While I am not sure of all the implementation details, from this we can say that it doesn't make sense to make poll() a wrapper for epoll. The programmer must be aware of these points, and existing code written with the assumptions poll() allows would break.

  • poll is much simpler for easy cases; it is probably just as efficient for small numbers of file descriptors. The caller doesn't need to worry about maintaining poll FDs and adding/removing FDs, they can just add all the ones they want on each call to poll.

    My feeling is that they are complimentary, although poll COULD be implemented as a wrapper for epoll, it probably shouldn't be.

    epoll could (almost) be implemented as a wrapper for poll, but that would defeat its efficiency arguments.

    From MarkR

0 comments:

Post a Comment