[issue1503] test_xmlrpc is still flakey

Ralf Schmitt added the comment: The tests now pass, but the underlying issue hasn't been fixed! -- ___ Python tracker ___ ___ Python-b

[issue1503] test_xmlrpc is still flakey

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue1503] test_xmlrpc is still flakey

Georg Brandl added the comment: I've not seen special failures of test_xmlrpc lately. -- nosy: +georg.brandl resolution: -> out of date status: open -> closed ___ Python tracker ___

[issue1503] test_xmlrpc is still flakey

Ralf Schmitt <[EMAIL PROTECTED]> added the comment: I would say without a decision on what to do, there will be no patch :) I can write a patch, which unconditionally turns on blocking mode for sockets returned from accept (on unix-platforms). Would that be fine? ___

[issue1503] test_xmlrpc is still flakey

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Without a patch this will not improve. ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Pyt

[issue1503] test_xmlrpc is still flakey

Ralf Schmitt <[EMAIL PROTECTED]> added the comment: I still think that blocking mode should be turned on in socket.accept. settimeout implicitly sets non-blocking mode (which might be a bit surprising). The sockets returned from accept() being in non-blocking mode is surprising (as this bug shows

[issue1503] test_xmlrpc is still flakey

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Does anybody still care about this? ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python

[issue1503] test_xmlrpc is still flakey

Neal Norwitz <[EMAIL PROTECTED]> added the comment: Ugh. The manpage for accept on Ubuntu 6.10 says: """ On Linux, the new socket returned by accept() does not inherit file status flags such as O_NONBLOCK and O_ASYNC from the listening socket. This behaviour differs from the canonical BS

[issue1503] test_xmlrpc is still flakey

Ralf Schmitt <[EMAIL PROTECTED]> added the comment: With the following diff, test_xmlrpc.py passes without problems. Like I said, someone else should decide where to turn on blocking mode. I now think that it should be in the socket.accept (i.e. in the C code) at least for unix platforms. Those

[issue1503] test_xmlrpc is still flakey

Ralf Schmitt <[EMAIL PROTECTED]> added the comment: No, please do not disable them. I'm not quite sure what to do, but apparently these sockets returned from accept should be turned into blocking sockets. I just do not know, where this should happen. I think that this could even be done inside th

[issue1503] test_xmlrpc is still flakey

Alan McIntyre <[EMAIL PROTECTED]> added the comment: It's my fault the xmlrpc tests try to use non-blocking sockets. That got added because sometimes failing tests would just sit there with the server blocking until the entire test process got killed for running too long. There are some tests t

[issue1503] test_xmlrpc is still flakey

Ralf Schmitt <[EMAIL PROTECTED]> added the comment: now that I see that the buildbot was running on ppc *Debian* I'm not quite sure if we're talking about the same issue. __ Tracker <[EMAIL PROTECTED]> ___

[issue1503] test_xmlrpc is still flakey

Ralf Schmitt <[EMAIL PROTECTED]> added the comment: I just double checked with the following program: #! /usr/bin/env python import os import fcntl import socket def isnonblocking(fd): return bool(fcntl.fcntl(fd, fcntl.F_GETFL, 0) & os.O_NONBLOCK) def main(): s=socket.socket()

[issue1503] test_xmlrpc is still flakey

Ralf Schmitt <[EMAIL PROTECTED]> added the comment: The current buildbot has errors similar to this one (I assume): Exception happened during processing of request from ('127.0.0.1', 53126) Traceback (most recent call last): File "/Users/ralf/trunk/Lib/SocketServer.py", line 281, in _handle_re

[issue1503] test_xmlrpc is still flakey

New submission from Guido van Rossum: See e.g.: http://www.python.org/dev/buildbot/3.0/ppc%20Debian%20unstable%203.0/builds/303/step-test/0 Note how it fails the first time and passes on the re-run. I've seen this before (just not on any of my own systems). I've also seen it fail twice (on bui