up vote 5 down vote favorite
share [g+] share [fb]

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.

link|improve this question
I don't think anyone has any idea what you are talking about. Are these system calls? On what systems/distributions? – bmargulies Jan 3 '10 at 19:46
3  
These are system calls. If you have no idea what he's talking about maybe you should look it up, but his question is perfectly valid. – spatz Jan 3 '10 at 19:49
1  
Both are syscalls to wait for any activity on a set of file descriptors. Epoll is specific to Linux 2.6+. I added links to man pages. – Nicht Verstehen Jan 3 '10 at 19:52
I know what they are. But there are many linux/unix like systems that have poll, and the question can't be answered without specifics as to which versions of what. – bmargulies Jan 3 '10 at 20:17
feedback

migrated from stackoverflow.com Jan 5 '10 at 8:33

This question came from our site for professional and enthusiast programmers.

2 Answers

up vote 2 down vote accepted

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.

link|improve this answer
1  
That is the most probable answer. I tested it and epoll is really 10 times slower than poll for 1 file descriptor of a local file (550 us per 1000 polls and 5420 us per 1000 epolls (create+ctl+wait+close)). epoll_wait solely was only 2 times slower than poll. – Nicht Verstehen Jan 3 '10 at 23:08
feedback
up vote 2 down vote

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.

link|improve this answer
1. Default flavour of epoll (Level-triggered) acts like poll (see Description section of manpage for epoll(7)). 2. Poll is essentially epoll_create+epoll_ctl+epoll+wait+close. So number of epoll descriptors used in this imaginary poll is bounded by the number of threads performing poll simultaneously. So there could be some technique to adjust max_user_instances to reflect the max number of threads. 3. I posted this question because of curiusity about what those assumptions were. – Nicht Verstehen Jan 3 '10 at 20:54
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.