Antoine Pitrou <pit...@free.fr> added the comment: I get the feeling (without actually investigating) that this is because a fork()-created process inherits all the parent's configuration, including (in this case) signal handlers and whatever file descriptor was configured to receive signal events using signal.set_wakeup_fd(). So the child process, when it receives a signal, also writes on that file descriptor which happens to be the same underlying self-pipe as in the parent.
In Python 3.6 it seems there isn't much you can't do against this (well, nothing obvious, in any case). In Python 3.7, you'll have two fixes available in ProcessPoolExecutor (*): * either pass an initializer function that resets signal configuration to a sane default state * or pass a "forkserver" multiprocessing context that will avoid inheritance issues in the process pool workers (*) see docs at https://docs.python.org/3.7/library/concurrent.futures.html#concurrent.futures.ProcessPoolExecutor I would generally recommend using "forkserver" whenever possible, since it eliminates all those inheritance issues by design. ---------- nosy: +njs, pitrou versions: +Python 3.7 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31489> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
