如何选择kqueue的EV_ONESHOT与EV_DISPATCH标志？

一、EV_ONESHOT和EV_DISPATCH的其他可见区别 #

• 资源占用差异：EV_ONESHOT触发事件后，会直接从kqueue的事件列表里删掉这个kevent，释放对应的内核资源；EV_DISPATCH只是禁用该事件条目，资源还留在kqueue里，只是不再给用户发事件通知。
• 复用成本不同：如果要再次监听，EV_ONESHOT得重新调用kevent()，把完整的kevent结构（过滤器、标识、数据等所有参数）重新填一遍；EV_DISPATCH只需要调用kevent()，给这个kevent加上EV_ENABLE标志就行，不用重复填其他配置，操作更省事。
• 状态保留区别：EV_DISPATCH禁用后，事件的配置信息还在，后续启用时直接复用；EV_ONESHOT删除后，所有配置都没了，只能从头创建。

二、如何选择这两个标志 #

• 选EV_ONESHOT的情况：
  • 只需要监听一次的事件，比如临时等某个文件描述符的单次可读/可写，之后再也不用管它了。
  • 想尽量省内核资源，不想留着没用的事件占空间。
• 选EV_DISPATCH的情况：
  • 需要反复启用、禁用同一事件的场景，比如周期性关注某个描述符，不想每次都重新写一遍kevent配置。
  • 想保留事件的配置信息，之后要恢复监听时能快速搞定的场景。

三、EV_DISPATCH时过滤器未禁用的效果 #

手册里说“过滤器本身不会被禁用”，实际效果是：

• 内核还是会按照过滤器的逻辑，盯着目标对象（比如文件描述符、定时器）的状态变化，只是不会把符合条件的事件推给用户空间。
• 举个实际例子：用EVFILT_READ过滤器加EV_DISPATCH监听一个socket，内核依然会跟踪这个socket有没有数据可读，当有数据进来时，过滤器能识别到这个状态，但因为EV_DISPATCH的存在，不会把这个事件放到用户的事件队列里。等之后用EV_ENABLE重新启用这个kevent时，内核会立刻把已经识别到的状态变化（如果有的话）发给用户，不用再等新的事件触发。

内容的提问来源于stack exchange，提问作者user2962393