For what it’s worth, the Python interpreter’s signal handling machinery already routes all signals to the main thread, in the sense that signal handlers always run inside the main thread (the one that started first). This is how the default KeyboardInterrupt
handling works: the signal handler can raise an exception (!), and then it propagates into whatever the main thread was doing when it paused to run the signal handler. There are some subtleties here around Unix vs. Windows, and C-level signal handlers versus Python-level signal handlers, but that’s the basic idea.
I think this is probably irrelevant though I don’t think there’s much demand for a Python structured concurrency library that uses actual threads.