Georg Brandl wrote:
Nick Coghlan schrieb:
Discussion of how to spell SIGKILL looks like bikeshed painting to me, but the question of how to extend graceful interrupt behavior to C modules looks worthy of an idea to me.
Is that too hard or too rare a need? If someone can come up with an adequate C API spelling of the change (e.g. a PYTHON_BEGIN_ALLOW_SIGINT_ABORT/PYTHON_END_ALLOW_SIGINT_ABORT) and define it in such a way that the burden for cleaning up before resumption of execution of Python code is placed on the developer using
Stephen J. Turnbull wrote: the new API then I'd be +1.
Do you think people would use it? It's already hard to convince them of using the thread state macros correctly, and the benefit of doing that is subjectively much larger (multithreading works without blocking) than for the SIGINT handling.
I think some of the major well-maintained extensions might be persuaded to use it (think numpy) and we'd be able to use it ourselves (time.sleep(), I'm looking at you). time.sleep() is actually a great example. Firstly, I didn't use it just yesterday precisely because dropping it in in a naive fashion would have broken Ctrl-C handling and I didn't feel like taking the time to use it in a less naive way. Secondly, it's a stateless call - if the sleep call is aborted due to a Ctrl-C, then the only thing to do before going back into Python code is reacquire the GIL. That said, my signal-handling-fu isn't even close to being able to handle writing the macros to make that happen. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------