Jesús Cea Avión <j...@jcea.es> added the comment: Checking the testsuite source code, I see several issues:
The server thread only waits for 3 seconds for the connection. If a connection is not created before 3 seconds, the server suicides and when the connection is tried, it will fail. This probably explain why the problem is sporadic and seems to depend of name resolving. If the DNS resolver is "slow", we have a problem. Also, the event is signaled twice in the server, and the client does a wait and a clear. If the thread scheduler is lucky, the server would signal twice and THEN the client would wait (and return inmediatelly) and clear, completelly missing the second signaling and hanging the client in the next wait (in the teardown). So, I would propose: 1. Use 127.0.0.1 instead of "localhost". 2. Delete the timeout in the server. I don't see the purpose of it, except be sure the server thread dies eventually. Lets configure the thread as "daemon", and don't mind with the thread join. 3. Cleanup the Event signaling. 4. "time.sleep(0.1)?"... Please... :-) Opinions?. I assign the issue to myself. Please, provide feedback and I will create & apply the patch. I have seen this issue too in 2.7, in my buildbots (OpenIndiana). You can reproduce the issue easily changing the "self.sock.settimeout(3)" to "self.sock.settimeout(0.01)", for instance. PS: I see use of test.support.HOST in the testuite, but that attribute is not documented anywhere. :-?? """ Python 3.2.2 (default, Sep 5 2011, 01:49:10) [GCC 4.4.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from test import support >>> support.HOST 'localhost' """ Should it be 127.0.0.1, or not use at all, since it is not documented?. PPS: I only checked telnetlib, not ftplib. ---------- assignee: -> jcea versions: +Python 2.7 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11812> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
