This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author njs
Recipients Ilya.Kulakov, njs, pitrou, yselivanov
Date 2017-12-19.18:59:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1513709982.43.0.213398074469.issue31489@psf.upfronthosting.co.za>
In-reply-to
Content
Ouch, yes, that's a tricky bug. This is definitely caused by the way that asyncio internally converts signals into messages along a pipe (well, socket, but same thing), and then after a fork-without-exec the child keeps writing into that pipe. It's exacerbated by asyncio's choice to use the self-pipe as its source of truth about which signals have arrived vs just a wake-up pipe (see [1]), but that's not really the main issue; even without this we'd get spurious wakeups and other unpleasantness.

In addition to the workarounds Antoine suggested, it would possibly make sense for forked children to disable any wakeup_fd, perhaps in PyOS_AfterFork or by adding a getpid() check to the C level signal handler. I can't think of any cases where you actually want to processes to share the same wake-up fd. And even if this isn't fixed at that level, it would make sense for asyncio to use the new atfork module to do something similar for asyncio specifically.

Also relevant: https://github.com/python/asyncio/issues/347

[1] https://github.com/dabeaz/curio/issues/118
History
Date User Action Args
2017-12-19 18:59:42njssetrecipients: + njs, pitrou, yselivanov, Ilya.Kulakov
2017-12-19 18:59:42njssetmessageid: <1513709982.43.0.213398074469.issue31489@psf.upfronthosting.co.za>
2017-12-19 18:59:42njslinkissue31489 messages
2017-12-19 18:59:42njscreate