epoll 或 kqueue 是否可以处理向自身异步添加文件描述符

Question

如果一个线程（比如 X）正在等待 epoll_wait()，另一个线程（比如 Y）可以调用 epoll_ctl() 以注册对文件描述符 9 的兴趣。之前在线程X中对epoll_wait()的调用能否返回线程Y添加的文件描述符9？对epoll_wait() 的初始调用在任何时候都不会在中间返回。

现在我想对此进行比较，并就操作系统中的另外两个轮询调用提出相关问题。 poll() 和 kqueue

1. 如果上述问题的答案是正确的，那么有没有办法通过poll() 系统调用实现类似的行为？
2. 让我们假设epoll_ctl() 是线程安全的，线程X 可以安全地调用epoll_ctl() 并让epoll_wait() 的调用返回文件描述符9 是否准备好进行I/O。声明对文件描述符感兴趣的函数和等待函数的分离是使这个函数令人惊叹的原因。但是人们经常将kqueue 和epoll 称为用于相同的功能。但是kqueue 没有单独的函数来声明对获取描述符的事件反馈感兴趣。有人知道kqueue 可以以与epoll 类似的方式使用吗？ epoll 似乎是目前最好的线程安全选项，如果它允许线程安全“利益声明”

Answer 1

来自man epoll_wait：

虽然一个线程在调用 epoll_pwait() 时被阻塞，但另一个线程可以将文件描述符添加到等待的 epoll 实例。如果新的文件描述符准备好，它将导致 epoll_wait() 调用解除阻塞。

所以epoll_wait 在等待时监视添加的文件描述符。

poll()/select() 无法实现这种行为，因为它们读取文件描述符集一次，因此无法修改当前轮询的文件描述符集。 p>

[当然，如果您将由epoll_create 创建的文件描述符传递给poll()/select()，则该文件描述符的修改将与epoll_wait 一样被跟踪。]