Spurious recv() EAGAIN on OSX?

Edit: Problem solved, I earlier incorrectly called fcntl(sock, F_SETFL, FD_CLOEXEC) on the server socket. This somehow got mapped to a mask containing O_NONBLOCK because FD_CLOEXEC is for F_SETFD, not F_SETFL and was inherited to client sockets too.

Hello,

I'm developing a networking application on Mac OS X 10.4. Something strange is happening here: Sometimes - pretty regularly and reliably - a recv() o开发者_如何学JAVAperation on a blocking TCP socket returns -1 with errno being set to EAGAIN.

This is very strange because, as stated, it is a blocking socket. Nor have I set any receive timeouts - which as the docs state can also cause an EAGAIN return. I used getsockopt() to verify that there is no timeout. If I slap in a usleep() and call recv() again, then I get data the next data just fine.

Has anyone encountered this before on OSX specifically or on other systems?

This application is pretty simple. It is single-threaded, makes no use of singals, there is no asynchronous I/O going on.

The man page reads:

[EAGAIN] The socket is marked non-blocking, and the receive operation would block, or a receive timeout had been set, and the timeout expired before data were received.

note the "timeout" part.

I found my mistake:

I called fcntl(fd, F_SETFL, FD_CLOEXEC); when I should have used F_SETFD for this flag :-(

I don't know how exactly this got mapped to a mask containing O_NONBLOCK - because they have different values - but that's what happened.

Thanks for your time.