如何使用 kevent 和 select？
kqueue() 返回的 kevent 的文件描述符可以用作 select() 或 kevent() 的输入。
使用这种方法有什么优点？
假设 kevent 正在使用 kevent() 等待描述符列表，并且该列表上有一些活动。 kevent 的文件描述符是否会被设置，可以通过 select() 或 kevent() 读取？
kevent's file descriptor returned by kqueue() can be used as input to select() or kevent().
What are the advantages of using this method?
Suppose kevent is waiting on a list of descriptors by using kevent() and there are some activities on that list. Will kevent's file descriptor be set, readable by select() or kevent()?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于 OSX/BSD - kevent 是 bsd/osx 可扩展性解决方案，与 Windows I/O 完成端口模型或 linux epoll 模型相当。
习惯后，我想我比其他模型更喜欢它的简单性和灵活性；尽管 API 的边缘有点粗糙。
与 select 相比，它的主要优势是规模。当与大量文件句柄一起使用时， 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 及更高版本中确实得到了改进。
For OSX/BSD - kevent is the bsd/osx scalability solution that is on par with the windows I/O Completion Port model, or the linux epoll model.
After getting used to it, I think I like it better than the other models for simplicity and flexibility; although the API is a little rough around the edges.
The primary advantage of this over select is scale. select() needs a lot of tricks and/or hacks to setup and tear down efficiently when used with a large number of file handles, and the number of file handles is often capped. poll() removes the limit on number of file handles, but still has the setup/teardown issues; and is not available natively in OSX.
I want to make an argument for improved context switching. This is true in windows IOCP, especially if using the new Vista APIs and the OS thread pooling. I believe it is true on OSX, but I would be hard pressed to give absolute examples.
For flexibility, it's nice that handles can be easily registered and removed from kqueues. But that's a convenience. The real nice thing with kevent is that it can associate with things that are not file handles. I prefer this to the epoll solution where everything has to be a file handle - yes, it's the unix mantra - but still some things have had to be hacked in to work with epoll.
kevents non-requirement on file descriptors lets you specifically monitor file reads, writes, attribute changes, deletion, renames. Process exits, forks, signals. events on a mach port (not on bsd). Timers, and user events.
It's really convenient to be able to handle all these kinds of events from a single API running on multiple threads using callback handlers.
So that was a very long winded answer to (1).
As for (2); I'm not sure I understand. I believe a single 'trigger activity' will cause kevent and select to trip should that file descriptor be pending in both.
One warning that is become less and less relevant. kevent on OSX 10.5.x is less than reliable. Some of the expected events just aren't supported and there are some bugs, or perhaps errata since the documentation of behaviour is vague. Such as... closing a socket/descriptor while waiting for it on a kevent may not trigger the kevent in some cases. From what I've seen kevent is OSX' underpinning technology for Grand Central Dispatch and it's really been improved in 10.6 and newer.