Charles-François Natali added the comment:
> 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/test_unix_sock_timeout.py
('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/test_unix_sock_timeout.py", 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.
----------
Added file: http://bugs.python.org/file37919/test_unix_sock_timeout.py
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23351>
_______________________________________import itertools
import os
import socket
import time
SOCKNAME = "/tmp/test.sock"
if os.fork() == 0:
time.sleep(1)
s = socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM)
s.settimeout(1)
for i in itertools.count():
print("sending ", i)
t0 = time.time()
try:
s.sendto("hello", SOCKNAME)
finally:
print("took {:.3f}s".format(time.time() - t0))
else:
os.remove(SOCKNAME)
s = socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM)
s.bind(SOCKNAME)
os.waitpid(-1, 0)_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
