On Tue, Sep 25, 2018 at 9:30 AM Gregory P. Smith <[email protected]> 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 _______________________________________________ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com