resource temporarily unavailable, os.EAGAIN, on TCP sockets

[Petar Maymounkov]

I have an HTTP ServerConn and a ClientConn on the same machine (two
different processes)
talking to each other.

The client simply sends requests to the server and server responds.

Once in a while, the call to ServerConn.Read() (which reads the next
request)
returns error 'resource temporarily unavailable' or os.EAGAIN.

I am somewhat confused as to why this happens.

Presumably the calls to net.Conn.Read() that happen inside
ServerConn.Read()
are blocking, so they should never return os.EAGAIN.

Can anyone shed light?

Thanks,
--Petar

[Alexey Borzenkov]

On Friday, April 8, 2011 10:53:51 PM UTC+4, Petar Maymounkov wrote:

Once in a while, the call to ServerConn.Read() (which reads the next
request)
returns error 'resource temporarily unavailable' or os.EAGAIN.

I am somewhat confused as to why this happens.

Are you using SetReadTimeout on the net.Conn? After looking through the net package it seems that after the read deadline is reached, the Read call will just return the EAGAIN that the underlying read syscall is returning.

 

Presumably the calls to net.Conn.Read() that happen inside
ServerConn.Read()
are blocking, so they should never return os.EAGAIN.

They are actually non-blocking underneath, the underlying implementation uses kqueue/epoll to wait the the actual read event. But it appears that even blocking sockets are supposed to return EAGAIN if timeouts are involved. See for example http://linux.die.net/man/2/recv for explanation of EAGAIN: "or a receive timeout had been set and the timeout expired before data was received."

Before I read that explanation of EAGAIN it was also puzzling to me (I thought it was supposed to return ETIMEOUT or something like that), but now it seems to click into place and the behavior must be correct.

[Petar Maymounkov]

I checked, and you are exactly correct. Thanks!

Thanks,
---Petar