0

kqueue() 返回的 kevent 的文件描述符可以用作 select() 或 kevent() 的输入。

  1. 使用这种方法有什么好处？

  2. 假设 kevent 正在使用 kevent() 等待描述符列表，并且该列表中有一些活动。kevent 的文件描述符会被设置，被 select() 或 kevent() 读取吗？

4

1 回答 1

1

对于 OSX/BSD - kevent 是与 windows I/O Completion Port 模型或 linux epoll 模型相当的 bsd/osx 可扩展性解决方案。

习惯了之后，我觉得我比其他机型更喜欢它的简单性和灵活性；虽然 API 有点粗糙。

这种选择的主要优势是规模。当与大量文件句柄一起使用时，select() 需要很多技巧和/或技巧来有效地设置和拆除，并且文件句柄的数量通常是有上限的。poll() 取消了对文件句柄数量的限制，但仍然存在设置/拆卸问题；并且在 OSX 中本机不可用。

我想为改进上下文切换提出一个论据。在 Windows IOCP 中确实如此，尤其是在使用新的 Vista API 和操作系统线程池的情况下。我相信这在 OSX 上是正确的，但我很难给出绝对的例子。

为了灵活性，句柄可以很容易地从 kqueue 中注册和删除，这很好。但这是一种方便。kevent 真正的好处是它可以与不是文件句柄的东西相关联。与 epoll 解决方案相比，我更喜欢这个解决方案，其中一切都必须是文件句柄 - 是的，这是 unix 的口头禅 - 但仍然有一些东西必须被破解才能使用 epoll。

kevents 对文件描述符的非要求允许您专门监视文件读取、写入、属性更改、删除、重命名。进程退出、分叉、信号。mach 端口上的事件（不在 bsd 上）。计时器和用户事件。

能够使用回调处理程序从在多个线程上运行的单个 API 处理所有这些类型的事件真的很方便。

所以这是对（1）的一个非常冗长的答案。

至于（2）；我不确定我是否理解。我相信如果文件描述符在两者中都挂起，则单个“触发活动”将导致 kevent 和 select 跳闸。

一个警告变得越来越不重要。OSX 10.5.x 上的 kevent 不太可靠。一些预期的事件只是不受支持，并且存在一些错误，或者可能是勘误表，因为行为的文档是模糊的。例如...在某些情况下，在 kevent 上等待它时关闭套接字/描述符可能不会触发 kevent。从我所见，kevent 是 OSX 为 Grand Central Dispatch 提供的基础技术，它在 10.6 和更新版本中确实得到了改进。

于 2012-03-04T20:34:27.463 回答