On Mon, Oct 10, 2016 at 12:05 AM, dieter <die...@handshake.de> wrote: > 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.
Thank you for the clear explanation. -- https://mail.python.org/mailman/listinfo/python-list
