On 2020-06-25 21:05, Yonatan Zunger via Python-ideas wrote:
Hey everyone,
I've been developing code which (alas) needs to operate in a runtime
environment which is quite /enthusiastic/ about sending SIGTERMs and the
like, and where there are critical short sections of code that, if
interrupted, are very hard to resume without some user-visible anomaly
happening. This means getting to know the signal handling logic far too
well. In particular, it means that preventing signals in a "dangerous
window" is very difficult in the current language: while you can change
the signal handlers to "suppressing" handlers and then restore them from
the main thread, if you have potentially critical regions running in any
non-main thread, there's no good way for them to tell the main thread to
change the handlers... except by sending the main thread a signal. That
requires the "suppressing" handler to have nontrivial logic in it,
/but/ Python signal handlers are reentrant: signals are not suppressed
/during a signal handler/, and so hilarity ensues.
Digging through all of this, though, there seems to be one interesting
thing that could be done in CPython in particular, and so I have a
possibly-crazy proposal for a runtime-specific extension.
*Proposal: Add (as an optional part of the spec, runtimes may choose to
implement if they wish) sys.suppress_signals(bool).* Calling this
function with a value of True would defer all signal handling until it
was called again with a value of False.
The reason this is potentially insane is that suppressing signals does
all sorts of things: e.g., it prevents keyboard interrupts, blocks
ENOPIPE errors if you try to write to a pipe with a terminated peer,
stops child processes from reporting their exit to the parent, screws
with profiling timers, and so on. This would be an a proper footgun if
misused, the sort of thing you should only activate if you actually
understand POSIX signals in depth.
The implementation in CPython would be surprisingly simple: simply store
the boolean value in an atomic int, and add a second check at the start
of _PyErr_CheckSignalsTstate
<https://github.com/python/cpython/blob/master/Modules/signalmodule.c#L1693>,
prior to clearing is_tripped.
How insane does this idea sound to people?
Wouldn't it be tidier as a context manager?
with sys.suppress_signals():
...
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/EWDLTCA3JYWRIFG2TTSYLW7WONGUEVDR/
Code of Conduct: http://python.org/psf/codeofconduct/
