[issue42913] asyncio.ProactorEventLoop mishandles signal wakeup file descriptor
Michel Hidalgo added the comment: Circling back. I've been giving some thought to this. While this could be fixed within asyncio.proactor_events.ProactorEventLoop and asyncio.unix_events._UnixSelectorEventLoop implementations (e.g. calling signal.set_wakeup_fd once and forwarding signal numbers to subsequent instances through file descriptors or direct reference), I can't help thinking I've encountered this issue of contending signal API calls too many times already. Rarely two call sites cooperate with each other. So... how do people feel about changing the signal API module to enable multiple file descriptors and multiple signal handlers per signal? It'd be much simpler to use, and not only in asyncio. Implementation-wise, a lock-free singly linked list could be used to store them (may need to expose compare-and-swap atomic primitives in pycore_atomic.h). -- ___ Python tracker <https://bugs.python.org/issue42913> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42913] asyncio.ProactorEventLoop mishandles signal wakeup file descriptor
New submission from Michel Hidalgo : asyncio.ProactorEventLoop uses a socket.socketpair and signal.set_wakeup_fd to wake up a loop that's polling I/O. However it does so with no consideration for file descriptors previously set (i.e. no signal number forwarding). Either by user code or by another instance of asyncio.ProactorEventLoop. The following snippet is enough for the above to cause the loop to hang forever: import asyncio import gc asyncio.set_event_loop(asyncio.ProactorEventLoop()) asyncio.set_event_loop(asyncio.ProactorEventLoop()) gc.collect() asyncio.get_event_loop().run_forever() The first asyncio.ProactorEventLoop instance sets a signal wakeup file descriptor on construction (see https://github.com/python/cpython/blob/187f76def8a5bd0af7ab512575cad30cfe624b05/Lib/asyncio/proactor_events.py#L632). The second instances does the same, dropping the file descriptor set by the first one (not good, not necessarily bad). When the garbage collector purges the first instance, signal wakeups are disabled completely (see https://github.com/python/cpython/blob/187f76def8a5bd0af7ab512575cad30cfe624b05/Lib/asyncio/proactor_events.py#L679). The loop cannot be interrupted with Ctrl+C anymore (bad). -- components: Windows, asyncio messages: 384979 nosy: asvetlov, hidmic, paul.moore, steve.dower, tim.golden, yselivanov, zach.ware priority: normal severity: normal status: open title: asyncio.ProactorEventLoop mishandles signal wakeup file descriptor type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue42913> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42913] asyncio.ProactorEventLoop mishandles signal wakeup file descriptor
Michel Hidalgo added the comment: Sorry for taking so long to reply. Sure, I would be happy to contribute. We should probably take care of Unix event loops -- since I opened this ticket I found out those tend to not cooperate with other signal wakeup file descriptor users either. I am a bit short on time right now though, so it will take some time. -- ___ Python tracker <https://bugs.python.org/issue42913> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
