我已将一个程序从 select 移植到 epoll，以增加我们可以处理的套接字数量。我已经将socket添加到epoll FD中并且可以愉快地读写了。
但是，即使我使用级别触发事件，我也担心套接字可能会饥饿。我担心的情况是，准备好的套接字数量多于epoll_event结构。我知道下次我打电话的时候epoll_wait它会给我其余的人，但我想知道我将他们按什么顺序排列，以考虑到上次和这次没有晋级的人。
一个例子：
假设我连接了 10 个套接字并将其添加到epollFD。我的内存只够 5 个epoll_event结构。让我们假设在每个之间的时间epoll_wait，所有 10 个套接字都接收数据。首先epoll_wait将返回 5epoll_event用于处理的结构，假设它是套接字 1-5。我处理这 5 个套接字，当我这样做时，更多的数据进来，所有 10 个套接字都有更多的数据需要读取。我输入epoll_wait再次获得 5 个以上epoll_event结构。
我的问题是第二次调用时我会得到哪 5 个套接字epoll_wait。是否是套接字 1-5，因为它们已添加到epoll先FD？或者我会得到套接字 6-10，因为这些事件是在更多数据进入套接字 1-5 之前引发的？
本质上，是epoll_wait就像 FIFO 队列一样，还是只是扫描内部套接字列表（从而优先考虑列表中的第一个套接字）。
编辑：
这是Linux内核v4.9.62
@jxh 关于该行为的观察是正确的，并且该行为早已确立（并且最初是有意的，如果我正确地记得我多年前与实施者 Davide Libenzi 的电子邮件对话）。不幸的是，迄今为止它还没有被记录下来。但是，我已经在即将发布的手册页版本中修复了这个问题，其中epoll_等待(2) http://man7.org/linux/man-pages/man2/epoll_wait.2.html将携带文本：
如果超过最大事件数文件描述符准备就绪时epoll_wait()被调用，然后连续epoll_wait()来电将会
循环遍历一组就绪的文件描述符。这
行为有助于避免进程失败的饥饿情况
注意到额外的文件描述符已经准备好了，因为它
重点关注一组已知的文件描述符
准备好。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
