我对基于事件的编程相当陌生。我正在试验 epoll 的 edge-mode，它显然只指示已准备好读/写的文件(与指示所有就绪文件的级别模式相反，无论是否已经准备就绪，或者刚刚准备就绪)。

我不清楚的是:在边缘模式下，我是否被告知在我未epoll_waiting 时发生的就绪事件？尚未重新装备的一次性文件上的事件如何处理？

为了说明我为什么这么问，请考虑以下场景:

• 连接了 10 个非阻塞套接字
• 配置 epoll_ctl 在套接字准备好读取时使用react，在 edge-mode + oneshot 中:EPOLLET | EPOLLONESHOT |埃波林
• epoll_wait 等待某事发生(最多报告 10 个事件)
• linux 唤醒我的进程并报告套接字 #1 和 #2 已准备就绪
• 我读取并处理数据套接字#1(直到E_AGAIN)
• 我读取并处理数据套接字#2(直到E_AGAIN)
• 当我这样做的时候，套接字S接收数据
• 我处理了所有事件，所以我在 EPOLL_CTL_MOD 模式下用 epoll_ctl 重新准备触发的文件，因为 oneshot
• 我的循环返回到epoll_wait处理下一批事件

好的，那么最后一个 epoll_wait 总是 会被通知 socket S 就绪了吗？ S 为 #1 时的事件(即未重新武装)？

最佳答案

I'm experimenting with epoll's edge-mode which apparently only signals files which have become ready for read/write (as opposed to level-mode which signals all ready files, regardless of whether there were already ready, or just became ready)

首先让我们清楚地了解系统，您需要一个关于系统工作原理的准确心智模型。您对 epoll(7) 的看法并不准确。

边沿触发和电平触发之间的区别在于对事件的确切定义。前者为文件描述符上订阅的每个 Action 生成一个事件；一旦你消费了这个事件，它就消失了——即使你没有消费产生这样一个事件的所有数据。 OTOH，后者会一遍又一遍地生成相同的事件，直到您使用了生成该事件的所有数据。

这是一个将这些概念付诸实践的例子，公然从 man 7 epoll 中窃取:

1. The file descriptor that represents the read side of a pipe (rfd) is registered on the epoll instance.

2. A pipe writer writes 2 kB of data on the write side of the pipe.

3. A call to epoll_wait(2) is done that will return rfd as a ready file descriptor.

4. The pipe reader reads 1 kB of data from rfd.

5. A call to epoll_wait(2) is done.

If the rfd file descriptor has been added to the epoll interface using the EPOLLET (edge-triggered) flag, the call to epoll_wait(2) done in step 5 will probably hang despite the available data still present in the file input buffer; meanwhile the remote peer might be expecting a response based on the data it already sent. The reason for this is that edge-triggered mode delivers events only when changes occur on the monitored file descriptor. So, in step 5 the caller might end up waiting for some data that is already present inside the input buffer. In the above example, an event on rfd will be generated because of the write done in 2 and the event is consumed in 3. Since the read operation done in 4 does not consume the whole buffer data, the call to epoll_wait(2) done in step 5 might block indefinitely.

简而言之，根本区别在于“事件”的定义:边缘触发将事件视为您消耗一次的单个单元； level-triggered 将事件的消耗定义为等同于消耗属于该事件的所有数据。

现在，让我们解决您的具体问题。

in edge-mode, am I informed of readiness events that happen while I'm not epoll_waiting

是的，你是。在内部，内核将每个文件描述符上发生的有趣事件排队。它们会在下次调用 epoll_wait(2) 时返回，因此您可以放心不会丢失事件。好吧，如果还有其他事件未决并且传递给 epoll_wait(2) 的事件缓冲区不能容纳所有事件，那么可能不会在下一次调用时发生，但关键是，最终这些事件将被报告.

What about events on one-shot files that haven't been rearmed yet?

同样，您永远不会丢失事件。如果文件描述符还没有重新装备，如果出现任何有趣的事件，它只是在内存中排队，直到文件描述符重新装备。一旦它被重新装备，任何未决事件——包括那些在描述符被重新装备之前发生的事件——将在下一次调用 epoll_wait(2) 时报告(同样，可能不会恰好是下一个，但它们会被报告)。换句话说，EPOLLONESHOT 不会禁用事件监视，它只是暂时禁用事件通知。

Ok, so will the last epoll_wait always be notified of the readiness of socket S? Event if S is #1 (i.e. it's not rearmed)?

鉴于我上面所说的，现在应该很清楚了:是的，它会的。您不会丢失任何事件。 epoll 提供了强有力的保证，它很棒。它也是线程安全的，您可以在不同线程中等待同一个 epoll fd 并同时更新事件订阅。 epoll非常强大，值得花时间学习!

关于linux - 没有 epoll_waiting 时是否正在监视 epoll 事件，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31581918/