[Python-Dev] Questions about signal handling. (original) (raw)

Eric Snow ericsnowcurrently at gmail.com
Tue Sep 25 11:39:47 EDT 2018

On Tue, Sep 25, 2018 at 9:30 AM Gregory P. Smith <greg at krypto.org> wrote:

We can't change the API of the main thread being where signal handlers are executed by default.

If a signal handler raised an exception in a daemon thread, the process would not die when it goes uncaught (ie: why KeyboardInterrupt works). The daemon thread ends and the rest of the process is unaware of that. Many existing Python signal handlers expect to only be called from the main thread.

Ah, that's good to know. Thanks, Greg!

If we wanted to change this, we'd probably want to have users declare which thread(s) are allowed to execute which signal handlers at signal handler registration time and whether they are executed by only one of those threads or by all of those threads. Not semantics I expect most people are used to because I'm not aware of any other language doing that. But I don't see a compelling use case for implementing such complexity.

That's similar to what I imagined, based on how signals and posix threads interact. Likewise I consider it not nearly worth doing. :)

Maybe something like that would make sense for subinterpreter delegation only? I'm not sure. I'd start without signals at all in subinterpreters before making such a decision.

Python keeping signals simple has long been cited as a feature of the VM.

Exactly. For now I was planning on keeping signals main-thread-only (consequently main-interpreter-only). There's the possibility we could support per-interpreter signal handlers, but I don't plan on exploring that idea until well after the more important stuff is finished.

-eric

More information about the Python-Dev mailing list