[Python-Dev] Questions about signal handling.

[Eric Snow]

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