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)
