为什么民意调查没有被epoll取代？

8

电平触发epoll与十分相似poll。为什么不poll只是epoll支持后者的系统的包装？

编辑：我的意思是，对于这种决定是否存在任何技术障碍？实施pollas epoll将大大提高许多网络应用程序的性能。应该有一些我没有注意到的技术问题。

linux

— Nicht Verstehen
source

5

这些是系统调用。如果您不知道他在说什么，也许您应该查一下，但是他的问题是完全正确的。

— drrlvn 2010年

2

两者都是系统调用，用于等待一组文件描述符上的任何活动。Epoll特定于Linux 2.6+。我在手册页中添加了链接。

我知道他们是什么。但是，有许多具有轮询功能的linux / unix之类的系统，没有具体说明哪个版本的问题就无法回答这个问题。

— bmargulies 2010年

实施poll为包装程序epoll将非常复杂且效率低下。您要么必须设置一个新的epoll描述符并每次对其进行配置，要么必须对当前轮询集与已经与epoll描述符关联的轮询集进行比较。！

— David Schwartz

2

在容易的情况下，民意测验要简单得多。对于少量的文件描述符，它可能同样有效。呼叫者不必担心维护轮询FD和添加/删除FD，他们只需在每次轮询中添加他们想要的所有FD。

我的感觉是它们是互补的，尽管民意调查可以作为epoll的包装器实施，但实际上不应该如此。

epoll可以（几乎）被实现为民意测验的包装器，但这将打败其效率论点。

— 标记
source

1

那是最可能的答案。我测试了它，epoll实际上比本地文件的1个文件描述符的轮询慢10倍（每1000个轮询550 us和每1000个epolls 5420 us（create + ctl + wait + close））。epoll_wait仅比轮询慢2倍。

1

的语义poll()和epoll是不同的。如果poll()通知您描述符是可读的，则您需要进行一些读取但不读取所有可用的字节，然后poll()再次将该描述符传递给它，它将立即唤醒。AFAIK并非如此epoll。

另请注意，epoll描述符是有限的资源。手册页讨论了epoll_create()AFAIK不会出现的故障情况poll()。

尽管我不确定所有的实现细节，但是由此我们可以说为进行poll()包装没有任何意义epoll。程序员必须意识到这些要点，并且在假设poll()允许的情况下编写的现有代码会中断。

1

1. epoll的默认风格（级别触发）的行为类似于民意测验（有关epoll（7），请参见手册页的“说明”部分）。2.轮询实质上是epoll_create + epoll_ctl + epoll + wait + close。因此，在此虚拟轮询中使用的epoll描述符数量受同时执行轮询的线程数量限制。因此，可能存在一些调整max_user_instances的技术以反映最大线程数。3.我发布这个问题的原因是对这些假设的好奇心。

1

好的，七年后，根据Evan Klitzke的这篇文章，我得到了一个更有说服力的答案。

首先，我首先问这个问题的原因是epoll与poll/ 相比经常提到的性能优势select。这个单词go epoll渐近地比poll（O（N））更有效（O（1 ））。

尚未广为人知的是，只有边沿触发 epoll才是真正的O（1），而电平触发则epoll具有相同的O（N）渐近性。确实，每次被调用以查找可能还有更多数据待处理的fds时，级别触发的味道就必须遍历受监视fds的列表。边缘触发的变化可以依靠信号来响应fd中出现的新字节。

找出恢复的线程如何确切地找出哪个fd唤醒了它会很有趣，但是在epoll触发的唤醒过程中肯定会传递此数据。

显然，poll/ select不能使用边缘触发， epoll因为语义是不同的。正如我们所看到的那样，使用级别触发的 实现epoll不会带来渐进的性能优势。而且，如果恒定因素或恒定条件较高，可能也会对其产生负面影响（因为它们似乎基于我所做的粗略基准，并在另一条评论中引用了该基准）。

有关更多信息，请阅读阻止I / O，非阻止I / O和Epoll。

— Nicht Verstehen
source