Signals and Threads in Python 3.5 or so

[dieter]

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.


Your problem description indicates that the problem is not
with signal handling by threads but with signal delivery by
the operating system.

In Linux, SIGINT signals in response to a "CTRL-C" are delivered
to the process group of the "control terminal".
Thus, with appropriate Linux calls, you can control whether or not
such a SIGINT is delivered to a subprocess.

Other operating systems may not provide such a control or it may
need different (OS dependent) calls.