[issue39651] Exceptions raised by EventLoop.call_soon_threadsafe

[Ben Darnell]

New submission from Ben Darnell <ben.darnell at 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 <report at bugs.python.org>
<https://bugs.python.org/issue39651>
_______________________________________