基于pidfd的epoll()后调用waitpid()的安全性保障问询

核心疑问解答：waitpid()不会阻塞 #

当epoll_wait()因pidfd可读被唤醒时，对应的子进程已经处于终止状态（要么成为僵尸进程，要么已完成退出清理），此时调用阻塞式waitpid(pid, &status, 0)会立刻返回，不会发生阻塞。

原因是：pidfd的可读事件触发时机，就是内核检测到子进程终止、且该进程的退出状态尚未被父进程获取时。一旦触发这个事件，子进程的退出状态已经就绪，waitpid()可以直接读取结果，无需等待。

方案的潜在问题与优化建议 #

• PID回绕导致的监控错误：Linux允许PID循环复用，若重启子进程时新进程PID恰好和刚终止的旧进程PID重复，且未正确关闭旧pidfd并关联新进程，会导致epoll监控错误的进程。解决方式：处理完终止事件后立即关闭旧pidfd，重启进程后创建新pidfd并添加到epoll实例。
• 边缘触发模式的事件遗漏：若使用epoll边缘触发（EPOLLET），需确保一次性处理完所有就绪的pidfd事件，否则可能漏掉后续终止事件。建议使用默认的水平触发模式，或在边缘触发下循环读取pidfd直到返回EAGAIN。
• waitpid参数的鲁棒性优化：即使确认不会阻塞，也可使用waitpid(pid, &status, WNOHANG)，避免极端场景（如其他线程提前调用waitpid获取了状态）下的阻塞，进一步提升稳定性。
• SIGCHLD与pidfd的竞争冲突：若进程管理器同时处理SIGCHLD信号，可能和pidfd事件处理产生竞争（比如信号处理函数先调用waitpid，导致pidfd事件处理时waitpid返回0）。建议统一使用pidfd+epoll的监控方式，避免依赖SIGCHLD。

无锁设计的注意事项 #

• 所有涉及pidfd和epoll实例的操作（添加、删除pidfd）尽量在单线程处理，或用原子操作保护共享数据结构。
• 处理终止事件、重启进程的逻辑，要避免修改其他线程正在访问的全局状态，或使用无锁数据结构管理进程列表。

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