选择系统调用的杂散就绪通知 [英] Spurious readiness notification for Select System call

问题描述

在 http://linux.die.net/man/2/select 上在错误"部分中，提到了选择系统调用有时可能会虚假地将FD设置为就绪，随后的读取调用将返回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.

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