[issue31388] Provide a way to defer SIGINT handling in the current thread

Jeroen Demeyer added the comment: Another idea I had is to somehow deal with this in PyErr_WriteUnraisable: whenever PyErr_WriteUnraisable is called for a KeyboardInterrupt, defer that exception to a later time, for example when _PyEval_EvalFrameDefault() is called. --

[issue31388] Provide a way to defer SIGINT handling in the current thread

Jeroen Demeyer added the comment: It's not only about ensuring that cleanup code gets run, but also about ensuring that the interrupt is actually seen. Currently, if you press CTRL-C at the "wrong" moment (during __del__), it will just get ignored. -- nosy:

[issue31388] Provide a way to defer SIGINT handling in the current thread

Nathaniel Smith added the comment: Sure, but whatever overhead it has, it has. Once we're paying for it, new keys are free (at yield/resume time). Compared to a bare thread-local it probably has somewhat higher overhead when we have to check it, but (a) that's why PEP 550 has a clever caching

[issue31388] Provide a way to defer SIGINT handling in the current thread

Antoine Pitrou added the comment: Le 08/09/2017 à 19:27, Nathaniel Smith a écrit : > > This seems a bit pointless if we have context local state available though, > because using context local state adds zero overhead to yields, and we yield > approximately 10,000,000x more frequently than we

[issue31388] Provide a way to defer SIGINT handling in the current thread

Nathaniel Smith added the comment: ... it's true I did write such an example. And a few lines up in the same message I wrote an example where I was protecting an event loop from interrupts. In both cases the tricky question is how to manage the transitions between protected and unprotected

[issue31388] Provide a way to defer SIGINT handling in the current thread

Antoine Pitrou added the comment: You just wrote an example where you are protecting __exit__ from interrupts. Do you schedule coroutines inside __exit__? -- ___ Python tracker

[issue31388] Provide a way to defer SIGINT handling in the current thread

Nathaniel Smith added the comment: Yes... low-level routines like coroutine schedulers where you need to defer interrupts inside the scheduler but not inside the coroutines being scheduled. It's not gold plating, it's actually the original motivation :-)

[issue31388] Provide a way to defer SIGINT handling in the current thread

Antoine Pitrou added the comment: Le 08/09/2017 à 03:54, Nathaniel Smith a écrit : > > The main feature we would like is for it to automatically vary depending on > the execution context -- in particular, naively sticking it into a > thread-local won't work, because if you use send/throw/next

[issue31388] Provide a way to defer SIGINT handling in the current thread

Nathaniel Smith added the comment: Note also that adding a check to ceval is not sufficient -- there are also lots of calls to PyErr_CheckSignals scattered around the tree, e.g. next to every syscall that can return EINTR. I've considered proposing something like this in the past, since it

[issue31388] Provide a way to defer SIGINT handling in the current thread

Nick Coghlan added the comment: Yes, it could also be done as a temporary global block on all signal and pending call processing, not just on SIGINT specifically. Either way, I'll also note that this can be a no-op in any thread other than the main thread, as those already delegate signal

[issue31388] Provide a way to defer SIGINT handling in the current thread

Antoine Pitrou added the comment: I think SIGINT handling is the wrong level to do this. Instead, it should be done at the ceval level, at the point where the "eval breaker" flag is examined for any interruption request to the normal sequential flow of execution. -- nosy: +pitrou

[issue31388] Provide a way to defer SIGINT handling in the current thread

New submission from Nick Coghlan: As discussed in issue 29988, it's currently difficult to write completely robust cleanup code in Python, as the default SIGINT handler may lead to KeyboardInterrupt being raised as soon as *any* Python code starts executing in the main thread, even when that