来自 epoll_wait 的事件的 epoll 顺序

Question

我已经将一个程序从 select 移植到 epoll，以增加我们可以处理的套接字数量。我已经把sockets加到epoll FD上，可以愉快的读写了。

但是，即使我使用的是级别触发事件，我也担心套接字可能会耗尽。我担心的情况是，准备好的套接字比epoll_event结构多。我知道下次我调用epoll_wait它时会给我其余的，但我想知道我让它们按什么顺序排列，并警告上次与这次没有晋级的人。

一个例子：假设我有 10 个套接字连接并添加到epollfd。我只有 5 个epoll_event结构的足够内存。让我们假设在每个 之间的时间内epoll_wait，所有 10 个套接字都接收数据。第一个epoll_wait将返回 5 个epoll_event结构进行处理，假设它是套接字 1-5。我处理了这 5 个套接字，在我这样做的同时，更多的数据进入并且所有 10 个套接字都有更多的数据要读取。我epoll_wait再次进入并获得另外 5 个epoll_event结构。

我的问题是在第二次调用epoll_wait. 会不会是插槽 1-5，因为它们是先添加到epollFD 中的？或者我会得到套接字 6-10，因为这些事件是在更多数据进入套接字 1-5 之前引发的？

本质上，epoll_wait就像一个 FIFO 队列，或者它只是扫描内部套接字列表（从而有利于列表中的第一个套接字）。

编辑：这是 Linux 内核 v4.9.62

Answer 1

@jxh 对行为的观察是正确的，而且这种行为早已建立（如果我正确地回忆起我多年前与实施者 Davide Libenzi 的电子邮件对话，这是最初的意图）。不幸的是，到目前为止它还没有被记录下来。但是，我已经修复了即将发布的手册页版本，其中epoll_wait(2)将携带文本：

如果在调用时有超过maxevents 个文件描述符准备就绪 epoll_wait()，则连续 epoll_wait()调用将通过准备好的文件描述符集循环。此行为有助于避免饥饿情况，即进程未能注意到其他文件描述符已准备就绪，因为它专注于一组已知已准备就绪的文件描述符。