我想知道以下情况是否真实？！
我知道在流行的桌面操作中出现错误，其中O_NONBLOCK TCP套接字，特别是那些在loopback接口上运行的套接字有时可以在select()报告套接字准备好读取之后从recv()返回EAGAIN 。 在我的情况下，这发生在另一方半关闭发送流之后。
有关更多详细信息，请参阅我的OCaml网络应用程序环境分发版的NX库中的t_nx.ml的源代码。 （ 链接 ）
对于recv()你会得到EAGAIN而不是EWOULDBLOCK ，是的，这是可能的。 由于您刚刚使用select()进行了检查，因此发生了以下两种情况之一：
这是可能的，但仅限于您有多个线程/进程尝试从同一套接字读取的情况。
在Linux上，它甚至记录了这可能发生，正如我读到的那样。
看到这个问题：
选择系统调用的虚假就绪通知
在multithreading环境中，两个线程从套接字读取是可能的。 这是一个multithreading应用程序吗？
如果你没有在这个套接字上调用select（）和recv（）之间的任何其他系统调用，那么recv（）将永远不会返回EAGAIN或EWOULDBLOCK。
我不知道它们对recv-timeout意味着什么，但是，POSIX标准在这里没有提到它，所以你可以安全地调用recv（）。
虽然我的应用程序是单线程的，但我注意到所描述的行为在RHEL5中并不罕见。 TCP和UDP套接字都设置为O_NONBLOCK（设置的唯一套接字选项）。 select（）报告套接字已准备就绪，但以下recv（）返回EAGAIN。
以上就是c/c++开发分享非阻塞套接字上的select（），recv（）和EWOULDBLOCK相关内容,想了解更多C/C++开发(异常处理)及C/C++游戏开发关注计算机技术网(www.ctvol.com)!)。
本文来自网络收集，不代表计算机技术网立场，如涉及侵权请联系管理员删除。
ctvol管理联系方式QQ:251552304
本文章地址：https://www.ctvol.com/c-cdevelopment/545660.html