See also CPython buildbots: test_read_pty_output fails on "AMD64 Snow Leop 3.x": http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/997/steps/test/logs/stdio (it is failing since the addition of the new test)
But test_asyncio succeeded on "x86 Tiger 3.x": http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/7668 Translation for myself: Version 10.4: "Tiger" Version 10.6: "Snow Leopard" Victor 2014/1/11 Guido van Rossum <[email protected]>: > I can't repro this one either on my Mac (64bit Macbook Air, OS X > 10.8.5, Darwin Kernel Version 12.5.0). > > I don't know how to tell which OpenSSL version I am using, but I > presume it's the Apple builtin 0.9.8. I tried both Python 2.6 (2.6.7 > built by Apple) and 2.7 (2.7.6+ built by me). > > (That doesn't mean there isn't a problem. It's just harder to reason > about when I can't repro it.) > > On Fri, Jan 10, 2014 at 9:45 AM, Guido van Rossum <[email protected]> wrote: >> I think you forgot to mention that this is in Trollius, not in Tulip. :-) >> >> I wonder if it may make sense to modify Tulip (and hence Trollius) to >> discard all scheduled events when stop() is called? Or perhaps only >> the ones that represent I/O callbacks? >> >> Or perhaps a cleaner way is to only really stop after the callbacks >> *currently* in the _ready queue have all been called. (This prevents >> never stopping because something always calls call_soon().) >> >> On Fri, Jan 10, 2014 at 2:04 AM, Victor Stinner >> <[email protected]> wrote: >>> Hi, >>> >>> test_events.test_create_server_ssl() hangs on my Mac OS 10.8 and >>> OpenIndiana VM which both are using Python 2.6 with OpenSSL 0.9.8. The >>> test hangs in _SelectorSslTransport._read_ready(). >>> >>> It looks like the hang occurs when the _run_once() method of the >>> (select) event loop is called with a call to _read_ready() already >>> scheduled. Said differently, when _run_once() exits because of the >>> StopError exception, while a call to _read_ready() is scheduled but >>> not executed yet. >>> >>> On my Linux box, the test pass: _read_ready() is called twice, but the >>> second call does nothing because sock.recv() raises a >>> SSLWantReadError. >>> >>> IMO it's a bug in Python ssl module: the socket is configured as >>> non-blocking, sock.recv() must never block. Is it a known issue? >>> >>> But can the issue also be seen as an asyncio bug? Is it safe and >>> efficient to call _read_ready() twice? I don't know if the issue only >>> occurs in unit test (which uses test_utils.run_briefly()) or if it may >>> also occur in an application (which can use >>> loop.run_until_complete(future)). >>> >>> Victor >> >> >> >> -- >> --Guido van Rossum (python.org/~guido) > > > > -- > --Guido van Rossum (python.org/~guido)
