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?

Yonatan

-- 

Yonatan Zunger

Distinguished Engineer and Chief Ethics Officer

He / Him

zun...@humu.com

100 View St, Suite 101

Mountain View, CA 94041

Humu.com <https://www.humu.com>  · LinkedIn
<https://www.linkedin.com/company/humuhq>  · Twitter
<https://twitter.com/humuinc>
_______________________________________________
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/AHWGT5XLC6QI73PCBWPXN4CEBJE5D42F/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to