kqueue（）返回的kevent文件描述符可以用作select（）或kevent（）的输入。
使用此方法有什么好处？
假设kevent正在使用kevent（）等待描述符列表，并且该列表上有一些活动。将kevent的文件描述符设置为可由select（）或kevent（）读取吗？
答案 0 :(得分：1)
对于OSX / BSD - kevent是bsd / osx可扩展性解决方案，与Windows I / O完成端口模型或linux epoll模型相同。
在习惯之后，我觉得我比其他型号更喜欢它，以简化和灵活;虽然API边缘有点粗糙。
这个选择的主要优点是规模。当与大量文件句柄一起使用时，select（）需要大量的技巧和/或黑客来有效地设置和拆除，并且文件句柄的数量通常是上限的。 poll（）删除文件句柄数量的限制，但仍然有设置/拆卸问题;并且在OSX中不可用。
我想为改进的上下文切换提出一个论据。在Windows IOCP中也是如此，特别是在使用新的Vista API和OS线程池时。我相信在OSX上也是如此，但我很难给出绝对的例子。
为了灵活性，手柄可以轻松注册并从kqueues中删除，这很好。但那是一种便利。 kevent真正的好处是它可以与不是文件句柄的东西相关联。我更喜欢epoll解决方案，其中一切都必须是文件句柄 - 是的，它是unix的口头禅 - 但是仍然有一些东西必须被黑客入侵才能使用epoll。
kevents对文件描述符的非必要性允许您专门监视文件读取，写入，属性更改，删除，重命名。处理出口，叉子，信号。马赫端口上的事件（不是在bsd上）。计时器和用户事件。
能够使用回调处理程序从多个线程上运行的单个API处理所有这些类型的事件非常方便。
这是对（1）的一个很长的回答。
至于（2）;我不确定我理解。我相信单个“触发器活动”将导致kevent并且如果文件描述符在两个文件中都处于挂起状态，则选择跳转。
一个警告变得越来越不相关。 OSX 10.5.x上的kevent不太可靠。一些预期的事件不受支持，并且存在一些错误，或者可能是勘误，因为行为记录模糊不清。例如...在kevent上等待它时关闭套接字/描述符可能在某些情况下不会触发kevent。从我所见，kevent是OSX支持Grand Central Dispatch的技术，它在10.6和更新版本中得到了很大的改进。