New submission from Dan O'Reilly: 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. ---------- components: asyncio files: handle_mp_unix.diff keywords: patch messages: 224082 nosy: dan.oreilly, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: _UnixDefaultEventLoop policy should either create a new loop or explicilty fail when get_event_loop() is called from a multiprocessing child process versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file36116/handle_mp_unix.diff _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22087> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
