[Python-Dev] Questions about signal handling.
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
More information about the Python-Dev