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 gvanrossum
Recipients gvanrossum, vstinner, yselivanov
Date 2014-09-14.23:45:32
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1410738333.05.0.00523038403284.issue21998@psf.upfronthosting.co.za>
In-reply-to
Content
Actually I expect that if you share an event loop across different processes via form, everything's a mess -- whenever a FD becomes ready, won't both the parent and the child be woken up?  Then both would attempt to read from it.  One would probably get EWOULDBLOCK (assuming all FDs are actually in non-blocking mode) but it would still be a mess.  The specific mess for the self-pipe would be that the race condition it's intended to solve might come back.

It's possible that some polling syscall might have some kind of protection against forking, but the Python data structures that map FDs to handlers don't know that, so it would still be a mess.

Pretty much the only thing you should expect to be able to do safely after forking is closing the event loop -- and I'm not even 100% sure that that's safe (I don't know what happens to a forked executor).

Is there a use case for sharing an event loop across forking?
History
Date User Action Args
2014-09-14 23:45:33gvanrossumsetrecipients: + gvanrossum, vstinner, yselivanov
2014-09-14 23:45:33gvanrossumsetmessageid: <1410738333.05.0.00523038403284.issue21998@psf.upfronthosting.co.za>
2014-09-14 23:45:33gvanrossumlinkissue21998 messages
2014-09-14 23:45:32gvanrossumcreate