Signals and Threads in Python 3.5 or so

[Dan Stromberg]

On Mon, Oct 10, 2016 at 12:05 AM, dieter <dieter at handshake.de> wrote:
> Dan Stromberg <drsalists at gmail.com> writes:
>> I have a program http://stromberg.dnsalias.org/~dstromberg/looper/
>> that I use and maintain.
>>
>> It's like GNU parallel or similar - yet another "run n processes, m at
>> a time" implementation.  Interestingly, I've only used/tested it on
>> Linux, but it's under a Microsoft copyright because Microsoft acquired
>> a Linux company I was working for.
>>
>> Anyway, it seems to work well, except one annoying bug.
>>
>> That bug is: if you control-C the top-level process, all the
>> subprocesses are left running.
>>
>> I've been thinking about making it catch SIGINT, SIGTERM and SIGHUP,
>> and having it SIGKILL its active subprocesses upon receiving one of
>> these signals.
>>
>> However, it's multithreaded, and I've heard that in CPython, threads
>> and signals don't mix well.
>
> I would not state it this way.
>
> Signals are delivered to processes (not process threads).
> That leads to the question which thread (in a multi thread application)
> will handle a signal when it arrives.
> In Python, the design decision has been not to use the currently
> running thread (which may not be a Python thread at all or
> may have executed Python code but at the moment runs C code outside
> of Python) but let the signal be handled deterministically by
> the main thread (once it starts again to execute Python code).
> This looks like a sane decision to me.

Thank you for the clear explanation.