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 dan.oreilly
Recipients dan.oreilly, gvanrossum, vstinner, yselivanov
Date 2014-07-26.18:01:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1406397670.19.0.283234608675.issue22087@psf.upfronthosting.co.za>
In-reply-to
Content
On non-Windows platforms, if a user attempts to use asyncio.get_event_loop() in a child process created by multiprocessing.Process using the fork context, and an asyncio event loop is also being used in the main process, the same _UnixSelectorEventLoop object will be used by both processes. This, of course, won't work properly; the child will raise a "RuntimeError: Event loop is running" exception as soon as it tries using the loop object.

However, this may or may not actually make it back to the parent: If the parent is expecting to get items from a queue from that child publishes to, rather than yielding from it immediately, the program will deadlock. Even if the child is yielded from, it may not be immediately obvious why "Event loop is running" was raised, and the behavior is inconsistent with the behavior if a method other than os.fork is used to create the child process, since the child will get a new event loop in that case.

So, it'd be better if _UnixDefaultEventLoopPolicy detected that get_event_loop was being called in a child process, and either 

1) Created a new loop for the child (this would make the behavior appear consistent no matter what platform/method for launching children is used)
2) Raised an exception stating that no default event loop exists for this process, similar to the assert used for threads currently.

I've attached a test script that demonstrates the different between forked/spawned processes, and a patch that implements #1 above.
History
Date User Action Args
2014-07-26 18:01:10dan.oreillysetrecipients: + dan.oreilly, gvanrossum, vstinner, yselivanov
2014-07-26 18:01:10dan.oreillysetmessageid: <1406397670.19.0.283234608675.issue22087@psf.upfronthosting.co.za>
2014-07-26 18:01:10dan.oreillylinkissue22087 messages
2014-07-26 18:01:09dan.oreillycreate