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)
