c++ - 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 :

While one thread is blocked in a call to epoll_pwait(), it is possible for another thread to add a file descriptor to the waited-upon epoll instance. If the new file descriptor becomes ready, it will cause the epoll_wait() call to unblock.

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

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

[当然，如果你将一个由 epoll_create 创建的文件描述符传递给 poll()/select()，这个文件描述符的修改将被跟踪为 epoll_wait.]