Select System 调用的虚假就绪通知 [英] Spurious readiness notification for Select System call

问题描述

在http://linux.die.net/man/2/select，在 BUGS 部分提到 select 系统调用有时可能会虚假地将 FD 设置为就绪，随后的 read 调用将返回 0.文本描述了一个这样的例子(错误的校验和)，但我假设也会有其他原因(否则他们会解决这个问题).

On http://linux.die.net/man/2/select, under BUGS section it is mentioned that the select system call may sometimes spuriously set the FD ready and the subsequent read call will return 0. The text describes one such example (wrong checksum) but I am assuming there would be other reasons too (otherwise they would have fixed this).

任何想法可能导致 Select 虚假返回 FD 的其他原因.

Any ideas what could the other causes for Select to return a FD ready spuriously.

这是否也适用于其他操作系统.我目前正在询问 Linux.

and does this apply to other OS'es also. I am currently asking about Linux.

以上链接的相关部分:

在Linux下，select()可能会报一个套接字文件描述符为准备好阅读"，尽管如此后续读取块.这可以为示例发生在数据到达时但经检查有误校验和被丢弃.也许有是文件的其他情况描述符被虚假报告为准备好.因此使用可能更安全O_NONBLOCK 在不应该的套接字上阻止.

Under Linux, select() may report a socket file descriptor as "ready for reading", while nevertheless a subsequent read blocks. This could for example happen when data has arrived but upon examination has wrong checksum and is discarded. There may be other circumstances in which a file descriptor is spuriously reported as ready. Thus it may be safer to use O_NONBLOCK on sockets that should not block.

推荐答案

这不完全是一个答案，但是看了epoll，这些问题似乎都为它解决了.

This is not exactly an answer, but looking over epoll, these problems seem to be solved for it.

如果我可以信任 netdev 中的此消息，他们至少尝试过也在 poll() 和 select() 中修复它(破坏其他东西).

And if I can trust this message in netdev, they at least tried to fix it in poll() and select() too (breaking other things).

因此，在可预见的未来，此错误似乎无关紧要.

Thus, this bug doesn't seem to be relevant in foreseeable future.

这篇关于Select System 调用的虚假就绪通知的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！