EPOLLET行为异常？为何epoll_wait在该场景下意外触发？

你遇到的问题核心是误解了EPOLLET（边缘触发）的工作机制——最后一次epoll_wait返回1是完全符合内核行为的，你的断言才是错误的。

我们一步步拆解代码执行流程，结合边缘触发的核心规则来解释：

边缘触发的核心逻辑是：epoll仅在文件描述符的就绪状态发生变化时才会触发事件，而不是只要描述符处于就绪状态就持续通知。

1. 初始状态：管道为空，读端处于「不可读」状态，第一次epoll_wait超时返回0，符合预期。
2. 写入12字节后：管道从「不可读」变为「可读」，状态发生变化，epoll_wait返回1，符合预期。
3. 再次调用epoll_wait：此时管道仍处于「可读」状态（数据未读取），没有新的状态变化，所以返回0，符合预期。
4. 读取12字节后：管道被读空，读端从「可读」变回「不可读」状态——这是一个状态变化，但因为你只关注EPOLLIN事件，epoll不会通知「不可读」的状态变更。
5. 写入3字节后：管道再次从「不可读」变为「可读」，这是一个全新的就绪状态变化，边缘触发会捕捉到这个变化，所以epoll_wait返回1——这才是正确的行为，你的断言assert(num_events == 0)错误地否定了这个逻辑。

简单来说：边缘触发并不关心你是否处理过之前的事件，它只看当前的就绪状态是否和上一次通知时的状态不同。当你把管道读空后，读端回到了「不可读」的初始状态，此时再写入数据，就相当于一次新的“从无到有”的就绪触发，epoll自然会返回事件。

如果你的预期是最后一次epoll_wait返回0，那你需要改变对边缘触发的理解——只有当读端处于「可读」状态时，再次写入数据才不会触发新事件（因为状态没变化），但这里你已经把管道读空，状态回到了「不可读」，新的写入必然触发状态变化。

内容的提问来源于stack exchange，提问作者Shachar Shemesh