Dan Stromberg <drsali...@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. -- https://mail.python.org/mailman/listinfo/python-list
