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()
andepoll
are different. Ifpoll()
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 intopoll()
again, it will wake up immediately. AFAIK the same is not true ofepoll
.Also note that
epoll
descriptors are a limited resource. The manpage talks aboutepoll_create()
failure conditions which AFAIK do not occurr withpoll()
.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 forepoll
. The programmer must be aware of these points, and existing code written with the assumptionspoll()
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