On Wed, 24 Jun 2020 16:54:34 -0700 Yonatan Zunger via Python-Dev <python-dev@python.org> wrote: > ... Reading through more of the code, I realized that I greatly > underestimated the number of interruptible operations. > > 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?
>From the top of my head, not really. Most of these (except the points you marked as "documented with the signal library") are really implementation details. The intent, though, is that any function waiting on an external event (this can be a timer, a socket, a lock, a directory...) should be interruptible so that Ctrl-C works in an interactive prompt. In general, I'd recommend 1) doing as little as possible with signals 2) doing as little as possible in signal handlers Note that if you do need to use signals, signal.set_wakeup_fd() can prevent you from interruption and reentrancy issues by allowing to wake up e.g. an event loop. Regards Antoine. _______________________________________________ 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/4YBJTG6CZ7KU4SPTK66EMM3B5ZSYHBCA/ Code of Conduct: http://python.org/psf/codeofconduct/
