Charles-François Natali <[email protected]> added the comment:
It's looping in Lib/asyncore.py:poll
select(4, [3], [3], [3], {30, 0}) = 1 (out [3], left {29, 999994})
select(4, [3], [3], [3], {30, 0}) = 1 (out [3], left {29, 999994})
select(4, [3], [3], [3], {30, 0}) = 1 (out [3], left {29, 999994})
loop sets the Unix domain socket in the writable set, and contrarily to
AF_INET/AF_INET6 sockets, bound AF_UNIX SOCK_STREAM sockets are reported as
writable before any client connects to them, which triggers the loop.
I've attached a patch which just doesn't add the socket to the writable set if
it's in the accepting state.
It fixes the loop, and doesn't seem to cause any regression in test_asyncore,
but since it's the first time I'm looking at asyncore's code, I might very well
have missed something :-)
----------
keywords: +patch
nosy: +neologix
Added file: http://bugs.python.org/file22586/asyncore_unix_socket.diff
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue12502>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
