Absolutely, but I figured the natural thing to expose from the C API was a very minimal function, and then put a context manager in the Python layer.
The actual context manager implementation I would use would be a bit smarter than a bare set/reset -- it would use an unbounded semaphore and only unsuppress when the count dropped to zero. That way, multiple threads can simultaneously have critical regions, and suppression would happen whenever anyone was suppressing. On Thu, Jun 25, 2020 at 1:54 PM MRAB <pyt...@mrabarnett.plus.com> wrote: > 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/ > -- 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/F6UFRA4N35RE2KFGGHPSXEGLMZFGVW4A/ Code of Conduct: http://python.org/psf/codeofconduct/
