我想知道以下情况是否真实?!
我知道在流行的桌面操作中出现错误,其中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