非阻塞套接字上的select(),recv()和EWOULDBLOCK
我想知道以下情况是否真实?!
- 非阻塞TCP套接字上的select()(RD)表示套接字已就绪
- 以下recv()将返回EWOULDBLOCK,尽管调用select()
我知道在流行的桌面操作中出现错误,其中O_NONBLOCK
TCP套接字,特别是那些在loopback接口上运行的套接字有时可以在select()
报告套接字准备好读取之后从recv()
返回EAGAIN
。 在我的情况下,这发生在另一方半关闭发送流之后。
有关更多详细信息,请参阅我的OCaml网络应用程序环境分发版的NX库中的t_nx.ml
的源代码。 ( 链接 )
对于recv()
你会得到EAGAIN
而不是EWOULDBLOCK
,是的,这是可能的。 由于您刚刚使用select()
进行了检查,因此发生了以下两种情况之一:
- 其他东西(另一个线程)已经在
select()
和recv()
之间排出了输入缓冲区。 - 在套接字上设置了接收超时,它在没有收到数据的情况下过期。
这是可能的,但仅限于您有多个线程/进程尝试从同一套接字读取的情况。
在Linux上,它甚至记录了这可能发生,正如我读到的那样。
看到这个问题:
选择系统调用的虚假就绪通知
在multithreading环境中,两个线程从套接字读取是可能的。 这是一个multithreading应用程序吗?
如果你没有在这个套接字上调用select()和recv()之间的任何其他系统调用,那么recv()将永远不会返回EAGAIN或EWOULDBLOCK。
我不知道它们对recv-timeout意味着什么,但是,POSIX标准在这里没有提到它,所以你可以安全地调用recv()。
虽然我的应用程序是单线程的,但我注意到所描述的行为在RHEL5中并不罕见。 TCP和UDP套接字都设置为O_NONBLOCK(设置的唯一套接字选项)。 select()报告套接字已准备就绪,但以下recv()返回EAGAIN。