Charles-François Natali <neolo...@free.fr> 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 <rep...@bugs.python.org> <http://bugs.python.org/issue12502> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com