[Python-3000] status of buildbots

Robert Brewer fumanchu at aminus.org
Wed Oct 31 17:00:55 CET 2007


Adam Hupp wrote:
> On 10/31/07, Neal Norwitz <nnorwitz at gmail.com> wrote:
> > We've made a lot of progress with the tests.  Several buildbots are
> > green.  http://python.org/dev/buildbot/3.0/
> >
> > There are some tests that are unstable, at least:
> >    test_asynchat test_urllib2net test_xmlrpc
> > http://python.org/dev/buildbot/3.0/g4%20osx.4%203.0/builds/170/step-
> test/0
> >
>
http://python.org/dev/buildbot/3.0/x86%20FreeBSD%203.0/builds/126/step-
> test/0
> 
> test_xmlrpc has code to ignore these but the error message has changed
> slightly so it's no longer in effect.
> 
> The reason for the errors is that the test is setting a timeout on the
> socket object which puts it in to non-blocking mode.  That's
> incompatible with SocketServer which uses socket.makefile for IO.  I
> don't think the timeout is necessary as long as one other fix is made.
>  I've asked the author of the test for confirmation.
> 
> On a related note, I think socket.makefile should throw an error if
> called on a non-blocking socket.  The docs are pretty unambiguous that
> this is wrong:
> 
> "file objects returned by the makefile() method must only be used when
> the socket is in blocking mode; in timeout or non-blocking mode file
> operations that cannot be completed immediately will fail."
> 
> Throwing an error would prevent things like this CherryPy issue:
> 
>  http://www.cherrypy.org/ticket/598
> 
> This doesn't help if the socket is put into non-blocking mode after
> makefile is called but it's better than nothing.
> 
> Alternatively, if the a timeout is set but non-blocking is *not*
> explicitly enabled the socket implementation could handle the retry
> loop itself.

That's the route I would prefer, and is probably what we're going to end
up doing for CherryPy (write our own makefile which retries). We prefer
the timeout for various reasons, yet WSGI requires file-like objects.


Robert Brewer
fumanchu at aminus.org


More information about the Python-3000 mailing list