级别触发的epoll与poll很相似。 为什么不是poll只是支持后者的系统的epoll包装？
编辑：我的意思是，有没有这种决定的技术障碍？ 将poll实现为epoll将大大提高许多networking应用程序的性能。 应该有一些技术问题，我没有注意到。
民意调查对于简单的情况要简单得多; 对于less量的文件描述符来说，它可能同样有效。 调用者不需要担心维护轮询FD和添加/删除FD，他们可以在每个调用中添加他们想要的所有轮询。
我的感觉是，他们是免费的，虽然民意调查可以作为epoll包装，它可能不应该是。
epoll可以（几乎）作为民意调查的封装来实现，但是这会打败它的效率论证。
poll()和epoll的语义是不同的。 如果poll()通知你描述符是可读的，那么你做一些读取，但不读取所有可用的字节，然后再次将该描述符传递给poll() ，它将立即唤醒。 AFAIK同样不是真的epoll 。
另外请注意， epoll描述符是有限的资源。 手册页谈到了epoll_create()失败的情况，AFAIK不会与poll() 。
虽然我不确定所有的实现细节，但是我们可以说，将poll()作为epoll的封装是没有意义的。 程序员必须意识到这些点，用假设poll()写的现有代码将允许中断。
好吧，7年后，我有一个更令人信服的答案根据这篇文章由埃文Klitzke。
首先，我首先提出这个问题的原因是epoll与poll / select相比经常提到的性能优势。 这个词表明， epoll比poll （O（ N ））渐近地更有效率（O（1））。
不为人所知的是，只有边缘触发的 epoll是O（1），而level-trggered的 epoll具有相同的O（ N ）渐近性。 事实上，每次被调用来查找可能还有更多数据悬而未决时， 级别触发的风格必须遍历所监视的fds的列表。 边缘触发的变化可以依靠信号来响应出现在fd中的新字节。
发现一个恢复的线程究竟是如何发现哪一个fd唤醒了它是有趣的，但是在epoll触发的唤醒过程中这个数据肯定是可能的。
显然， poll / select不能使用边缘触发的 epoll因为语义不同。 正如我们所看到的，用水平触发的 epoll实现不会带来渐近的性能好处。 如果常数因素或常数项很高（因为它们似乎是基于我在另一个评论中引用的粗略基准），也可能对其产生负面影响。
有关更多信息，请阅读阻止I / O，非阻塞I / O和Epoll 。