Kqueue (边缘触发)：短读是否意味着已失去了读准备状态？
当使用Linux 处于边缘触发模式(EPOLLET)时，读/写在EAGAIN/EWOULDBLOCK中失败，这意味着读写准备状态丢失，并且一旦恢复就绪状态，就保证通过epoll_wait()提供新的就绪事件。
此外，当在边缘触发模式和非阻塞流模式套接字中使用Linux 时，如果我们注册了对EPOLLRDHUP事件的兴趣，并且还没有收到EPOLLRDHUP事件，那么短读/写入(返回值小于请求的大小)也意味着读写准备的丢失，而且在恢复就绪时，我们仍然可以依赖一个新的就绪通知，即使EAGAIN/EWOULDBLOCK没有读写失败。
类似地，当在边缘触发模式( Kqueue，macOS/FreeBSD)中使用EAGAIN/EWOULDBLOCK时，读写失败意味着读写准备丢失，并且一旦恢复就绪，就保证通过kevent()提供新的就绪事件。
问题：在以边缘触发模式和非阻塞流模式套接字处理Kqueue时，如果我们注册了对EV_EOF事件的兴趣，并且还没有收到EV_EOF事件，是否有类似的保证，短读/写入意味着读写就绪的丢失，并且保证在恢复就绪时会产生新的就绪事件？
编辑：备注:知道短读意味着失去读准备状态，我(在一般情况下)可以避免重复调用read()，以避免EAGAIN/EWOULDBLOCK失败。
在Linux的上下文中，短读/写的含义来自epoll(7)手册页中的以下评论：
对于面向流的文件(例如管道、FIFO、流套接字)，也可以通过检查从/写入目标文件描述符读取的数据量来检测读/写I/O空间耗尽的条件。例如，如果通过请求读取一定数量的数据来调用read(2)，并且read(2)返回较低的字节数，则可以确保文件描述符的读取I/O空间已经耗尽。在使用write(2)编写时也是如此。(如果无法保证监视的文件描述符始终引用面向流的文件，请避免使用后一种技术。)
回答 1
Stack Overflow用户
发布于 2016-10-27 22:54:23
您可以询问“边缘触发模式下的 kqueue ”，但是kqueue文档没有使用该术语。我认为您的意思是您已经为有关事件启用了EV_CLEAR标志，其结果是
用户检索事件后，其状态将被重置。
(kqueue())
此外，您还规定该程序具有
注册了对
EV_EOF事件的兴趣，并且还没有收到EV_EOF事件
但是EV_EOF本身并不是一个事件；相反，它是一些可用的过滤器在适当的时候会设置的标志，特别是EVFILT_READ。
总之，你问题的核心是
是否有类似的保证，即短读/写意味着读写准备的丢失，以及在恢复就绪时保证产生一个新的就绪事件？
就我所能确定的情况而言，不能保证短时间读取就意味着失去了读准备状态，无论是对于BSD还是Linux。实际上，用于read(2)的Linux文档特别要求接收一个信号，作为短读的一个可能的替代原因。
此外，Linux epoll()文档推荐的用于边缘触发模式的非阻塞文件描述符的使用模型是反复读取，直到EAGAIN读取失败为止，使用它作为文件结束前准备就绪的指示。对于具有EV_CLEAR的事件，我建议在kqueue系统中遵循相同的策略。
我认识到您希望通过在短时间内停止访问来保存一个read()调用，但我认为这会给进程带来真正的风险，至少不会让传入的数据流无限期地得不到服务。此外，您的关注还为时过早，除非您已经确定这些额外的读取会导致可测量的、不可接受的性能流失。
https://stackoverflow.com/questions/40123626
复制相似问题
腾讯云开发者
