Errno 35 (EAGAIN) returned on recv call

Question

I have a socket which waits for recv and then after receiving data, sends data forward for processing. However, then it again goes for recv, and this time it receives nothing returns -1 and when printed the errno it prints 35 (which is EAGAIN).

This happens only on MAC OS Lion operating system, for other OS this runs perfectly fine

do{
 rc = recv(i, buffer, sizeof(buffer), 0);
 if (rc < 0){
      printf("err code %d", errno); 
 }
 if(rc == 0){ 
      //Code for processing the data in buffer 
      break; 
 } 
      ....
}while(1);

EDIT: Corrected indentation and errno

Solution 1

You either set the socket to non-blocking mode or enabled the receive timeout. Here's from recv(2) on a mac:

The calls fail if:

[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.

Edit 0:

Hmm, apologies for quoting again. This time from intro(2):

11 EDEADLK Resource deadlock avoided. An attempt was made to lock a system resource that would have resulted in a deadlock situation.

...

35 EAGAIN Resource temporarily unavailable. This is a temporary condition and later calls to the same routine may complete normally.

Just use strerror(3) to figure out the actual issue.

Solution 2

Your socket is in non-blocking mode. EAGAIN is the normal return from recv() (and other system calls) when there is no data available to read. In that sense it's not really an error.

If you meant for your socket to be nonblocking then you need to monitor it to find out when it has data available and only call recv() when there is data available. Use poll() (or kqueue, which is specific to FreeBSD and MacOS) to monitor is. Usually this is done in your application's main event loop.

If you did not mean for your socket to be nonblocking, then you should set it to blocking more with fcntl():

flags = fcntl(i, F_GETFL, 0); /* add error checking here, please */
flags &= ~O_NONBLOCK;
fcntl(i, F_SETFL, flags); /* add more error checking here! */

But you should be aware that the default blocking state of sockets (and all file descriptors) is blocking, so if your socket is in nonblocking mode then that means someone or something has manually made it nonblocking.

In blocking mode, the recv call will block and wait for more data instead of returning EAGAIN (or EWOULDBLOCK which is the same thing as EAGAIN).

Comments

[user207421]

Blocking mode is the default. If he didn't mean it to be non-blocking he should remove the code that sets that, not add more code to unset it.

[VijayKumar]

Thanks for your comment, however the error it returns is EDEADLK. And as said in previous comment I have no sleep in my calling code. Any ideas, as to why this occurs only in Mac OS Lion and not in Snow Leopard?

[VijayKumar]

Thanks for the comment Celada, the erro 35 however points me to EDEADLK rather than EAGAIN which in my case would be 41? Is there some mismatch in error codes ?

[Celada]

@EJP True. I was thinking from the point of view that the file descriptor might have come from some sort of library that always returns nonblocking sockets. That could explain how your socket could be nonblocking without you knowing it. Far-fetched, I know. Anyway the OP has since clarified that it was non-blocking on purpose

[VijayKumar]

More point to add is that first the data is fetched correctly in buffer, processed it and then since its a while loop, it again goes back to recv where it errors out with errno 35 - Now its confusing for me since it points me to EDEADLK while you say it EAGAIN...

[VijayKumar]

I know I would sound crazy here however, Could it be that errno are OS dependent? Since in MAC OS Snow Leopard this code works fine without any issues and its only Lion that this issue appeared.. Just a wild guess, you can beat me if this is really really crazy comment...

[VijayKumar]

You are correct @Celada, it does points to EAGAIN in MAC OS Snow Leopard

[VijayKumar]

I decided to ignore this error in this case to continue the flow of program

[Nikolai Fetissov]

Then you'd be busy looping until you receive data - not the best decision in by far most cases.

[VijayKumar]

So, an open question to all now, that I have ignored the error for the moment, starts working. What should I do with this question? Which answer is to be marked? I have seen many stackoverflow post where the users are not marking the correct answers, leading to confusion, which I dont want to add to ...Open for fair suggestions.

[Nikolai Fetissov]

Oh, obviously my answer is the only ever always by far the correct one :)

[Guss]

In my system (iOS simulator), I get 35, for which strerror() reports the error message for EDEADLK.