移植FreeBSD kevent代码到Linux：epoll_ctl是否需检查EINTR？

核心问题：epoll_ctl是否需要检查EINTR？ #

不需要。epoll_ctl属于非阻塞式的快速系统调用，它的添加、修改、删除事件操作都是在内核中快速完成的（主要是操作epoll实例的红黑树结构），不会进入可被信号中断的阻塞等待流程。因此，epoll_ctl永远不会返回EINTR错误码，你不需要在代码中针对这个错误做重试逻辑。

对比epoll_pwait（或epoll_wait）这类会阻塞等待事件的调用，它们属于慢系统调用，收到未屏蔽的信号时会返回EINTR，所以需要处理重试，但epoll_ctl不存在这个场景。

epoll源码阅读建议 #

如果想自行验证，推荐从Linux内核的fs/eventpoll.c文件入手，这是epoll机制的核心实现：

• 先定位到sys_epoll_ctl函数（epoll_ctl的系统调用入口），查看它的处理流程：你会发现整个函数没有检查signal_pending()的逻辑（内核判断是否有未处理信号的关键函数），也不会主动返回-EINTR（内核层错误码，用户态会转成EINTR）。
• 对比sys_epoll_wait或sys_epoll_pwait函数，里面有明确的信号检查逻辑，检测到未处理信号时会返回-EINTR，这也是这类调用需要处理EINTR的原因。
• 可以进一步看epoll_ctl具体操作的实现，比如ep_insert（添加事件）、ep_modify（修改事件）、ep_remove（删除事件），这些都是对红黑树的快速操作，全程不会阻塞，自然不会被信号中断。

另外，阅读前可以先把epoll的用户态手册（man epoll）吃透，先搞懂各个调用的功能和参数，再看内核源码会更顺畅。

内容的提问来源于stack exchange，提问作者jorge is not ai