On Fri., 26 Jun. 2020, 7:02 am Chris Jerdonek, <chris.jerdo...@gmail.com> wrote:
> On Wed, Jun 24, 2020 at 5:15 PM Yonatan Zunger via Python-Dev < > python-dev@python.org> wrote: > >> That said, the meta-question still applies: Are there things which are >> generally intended *not* to be interruptible by signals, and if so, is >> there some consistent way of indicating this? >> > > Yonatan, Nathaniel Smith wrote an interesting post a few years ago that > includes some background about signal handling: > https://vorpus.org/blog/control-c-handling-in-python-and-trio/ > Related to that is this CPython bug report: https://bugs.python.org/issue29988 The short version is that Greg Smith and I tried to close some of the remaining signal safety holes a couple of years ago, and I made it as far as building better tools for provoking the bugs (this is the origin of per-opcode tracing hooks in CPython), but we never came up with an actual solution. So the workaround remains to run anything that absolutely cannot be interrupted by poorly timed signals in a subthread, and dedicate the main thread to signal handling. Cheers, Nick. >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/UIBSEBHFMVEUQ6FMEIJEQFH42RCNRE2A/ Code of Conduct: http://python.org/psf/codeofconduct/
