OSX上的虚假recv（）EAGAIN？

编辑：问题解决了，我之前在服务器套接字上错误地调用了fcntl（sock，F_SETFL，FD_CLOEXEC）。这不知何故被映射到包含O_NONBLOCK的掩码，因为FD_CLOEXEC用于F_SETFD，而不是F_SETFL，并且也被继承到客户端套接字。OSX上的虚假recv（）EAGAIN？

你好，

我正在Mac OS X 10.4上开发网络应用程序。这里发生了一些奇怪的事情：有时 - 相当经常和可靠 - 对阻塞TCP套接字的recv（）操作返回-1，并将errno设置为EAGAIN。

这很奇怪，因为如前所述，它是一个阻塞套接字。我也没有设置任何接收超时 - 作为文档状态也可以导致EAGAIN返回。我使用getsockopt（）来验证没有超时。如果我打了一个usleep（）并再次调用recv（），那么我得到的数据就是下一个数据。

有没有人在OSX上专门或在其他系统上遇到过这个问题？

这个应用程序非常简单。它是单线程的，不使用信号，没有异步I/O进行。

2011-03-28 gnu

可能重复[阻塞套接字返回EAGAIN]（http://stackoverflow.com/questions/735249/blocking-socket-returns-eagain） – 2011-03-28 03:17:38

手册页读取：

[EAGAIN]套接字被标记无阻塞，并且接收操作会阻塞，或接收超时已被设定，并且超时数据过期之前收到了。

请注意“超时”部分。

2011-03-28 03:19:31

就像我说的，没有超时设置。就像我说的，我使用getsockopt（）验证了这一点，它看起来像O_NONBLOCK被设置，但我没有在任何地方请求O_NONBLOCK。 – gnu 2011-03-28 03:20:00

，我发现我的错误：

我打电话使用fcntl（fd，F_SETFL，FD_CLOEXEC）;当我应该用F_SETFD这个标志:-(

我不知道这是怎么精确匹配含有O_NONBLOCK面具 - 因为他们有不同的价值观 - 但这是发生了什么事

谢谢您时间

2011-03-28 03:39:05 gnu

回答