Author pitrou
Recipients Ilya.Kulakov, njs, pitrou, yselivanov
Date 2017-12-19.15:01:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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

I would generally recommend using "forkserver" whenever possible, since it eliminates all those inheritance issues by design.
Date User Action Args
2017-12-19 15:01:12pitrousetrecipients: + pitrou, njs, yselivanov, Ilya.Kulakov
2017-12-19 15:01:12pitrousetmessageid: <>
2017-12-19 15:01:12pitroulinkissue31489 messages
2017-12-19 15:01:12pitroucreate