Author neologix
Recipients neologix, piotrjurkiewicz, pitrou
Date 2015-01-30.08:03:13
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
> The way socket timeouts are implemented is by using select() to determine whether the socket is ready for read/write. In this case, select() probably marks the socket ready even though the queue is full, which later raises EAGAIN.

Indeed, and this looks like a kernel bug.

Working as expected on a RHEL6:

$ python /tmp/
('sending ', 0)
took 0.000s
('sending ', 1)
took 0.000s
('sending ', 2)
took 0.000s
('sending ', 3)
took 0.000s
('sending ', 4)
took 0.000s
('sending ', 5)
took 0.000s
('sending ', 6)
took 0.000s
('sending ', 7)
took 0.000s
('sending ', 8)
took 0.000s
('sending ', 9)
took 0.000s
('sending ', 10)
took 0.000s
('sending ', 11)
took 1.000s
Traceback (most recent call last):
  File "/tmp/", line 17, in <module>
    s.sendto("hello", SOCKNAME)
socket.timeout: timed out

> About SO_SNDTIMEO and SO_RCVTIMEO, POSIX says "it is implementation-defined whether the SO_SNDTIMEO option can be set". Also, they would not necessarily apply to other operations such as accept().

Exactly, the current way timeouts are implemented ar The Right Way, IMO.
File name Uploaded neologix, 2015-01-30.08:03:12
Date User Action Args
2015-01-30 08:03:13neologixsetrecipients: + neologix, pitrou, piotrjurkiewicz
2015-01-30 08:03:13neologixlinkissue23351 messages
2015-01-30 08:03:13neologixcreate