New submission from Ben Darnell <ben.darn...@gmail.com>:
Proactor and selector event loops behave differently when call_soon_threadsafe
races with a concurrent call to loop.close(). In a selector event loop,
call_soon_threadsafe will either succeed or raise a RuntimeError("Event loop is
closed"). In a proactor event loop, it could raise this RuntimeError, but it
can also raise an AttributeError due to an unguarded access to self._csock.
https://github.com/python/cpython/blob/1ed61617a4a6632905ad6a0b440cd2cafb8b6414/Lib/asyncio/proactor_events.py#L785-L787
Comments in BaseSelectorEventLoop._write_to_self indicate that this is
deliberate, so the `csock is not None` check here should probably be copied to
the proactor event loop version.
https://github.com/python/cpython/blob/1ed61617a4a6632905ad6a0b440cd2cafb8b6414/Lib/asyncio/selector_events.py#L129-L136
I'd also accept an answer that the exact behavior of this race is undefined and
it's up to the application to either arrange for all calls to
call_soon_threadsafe to stop before closing the loop. However, I've had users
of Tornado argue that they use the equivalent of call_soon_threadsafe in
contexts where this coordination would be difficult, and I've decided that
tornado's version of this method would never raise, even if there is a
concurrent close. So if asyncio declines to specify which exceptions are
allowed in this case, tornado will need to add a blanket `except Exception:`
around calls to call_soon_threadsafe.
----------
components: asyncio
messages: 362078
nosy: Ben.Darnell, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Exceptions raised by EventLoop.call_soon_threadsafe
versions: Python 3.8
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue39651>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
