Articles like these reinforce that almost all software is held together by prayers and pretends rare events never happen. We are a long distance away from verifiably correct systems.
I was surprised to find that it is possible (though unlikely, as it has to happen in a very narrow window of time between two particular bytecodes) for a KeyboardInterrupt to cause a with block to exit without the __exit__ method of the context manager running.
One thing I like from common lisp that hasn't caught on in other languages is that there is the option for exception handlers to run in the stack frame of where the exception occurs.
That seems like it could solve this issue, as the handler itself could tell if it were in trio code, and register a deferred exception only in that case, before the stack was ever unwound.
Control-C handling is pretty horrendous in C/C++ multithreaded programs, too. I remember writing code to re-dispatch the signal to the actual main thread, as a different signal, so that we could actually run an interactive menu in the handler.
(It turns out that while you "shouldn't" do POSIX IO from a signal handler, on Linux this works fine 99% of the time so you can write() a menu and read() the input character before deciding whether to stop your program cleanly or uncleanly.)
5 comments
[ 4.6 ms ] story [ 14.8 ms ] threadhttps://bugs.python.org/issue29988
That seems like it could solve this issue, as the handler itself could tell if it were in trio code, and register a deferred exception only in that case, before the stack was ever unwound.
(It turns out that while you "shouldn't" do POSIX IO from a signal handler, on Linux this works fine 99% of the time so you can write() a menu and read() the input character before deciding whether to stop your program cleanly or uncleanly.)