Whew. Nick, Antoine, and Chris, thanks to each of you for your feedback -- with it, I *think* I've managed to write a pure-Python signal suppression library. I'm nowhere near confident enough in its handling of corner cases yet to release it to the general public, but hopefully I'll be able to acquire that faith in it over time and do that.
(It ended up involving a new & improved Semaphore class with some more functions like pausability, having a signal handler that puts things in a SimpleQueue [thanks, Antoine] and dequeues them when the semaphore is empty and paused, creative use of with instead of try/finally to leverage some of the ideas in the blog post Chris linked and manage reentrancy, and with all that allow the main thread to meaningfully know when it needs to defer dealing with a signal until later so that the threads can safely finish. Whew.) Good rule of thumb: If your Python code has comments talking about specific opcodes, you are writing some Really Interesting Python Code. :) Yonatan On Sat, Jun 27, 2020 at 10:26 PM Nick Coghlan <ncogh...@gmail.com> wrote: > 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. > > > >> -- 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-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/VMKL26EOUELDRG24JLYN6RIQW25N4BXV/ Code of Conduct: http://python.org/psf/codeofconduct/
