[issue22087] _UnixDefaultEventLoopPolicy should either create a new loop or explicilty fail when get_event_loop() is called from a multiprocessing child process

STINNER Victor added the comment: This issue looks to be a duplicate of #21998. handle-mp_unix2.patch looks more to a workaround than a real issue. When I write asyncio code, I prefer to pass explicitly the loop, so get_event_loop() should never be called. IMO the methods of the event loop

[issue22087] _UnixDefaultEventLoopPolicy should either create a new loop or explicilty fail when get_event_loop() is called from a multiprocessing child process

Dan O'Reilly added the comment: Are any other changes needed here? I'm still not completely clear on what Victor meant with his last comment. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22087

[issue22087] _UnixDefaultEventLoopPolicy should either create a new loop or explicilty fail when get_event_loop() is called from a multiprocessing child process

STINNER Victor added the comment: See aslo issue #21998: asyncio: a new self-pipe should be created in the child process after fork. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22087

[issue22087] _UnixDefaultEventLoopPolicy should either create a new loop or explicilty fail when get_event_loop() is called from a multiprocessing child process

Dan O'Reilly added the comment: I've added a unit test that spawns a new forked process via multiprocessing, and verifies that the loop returned by get_event_loop is not the same as the one we have in the parent. -- Added file:

[issue22087] _UnixDefaultEventLoopPolicy should either create a new loop or explicilty fail when get_event_loop() is called from a multiprocessing child process

Dan O'Reilly added the comment: re: #21998, perhaps it's time to revive #16500? Without that, I'm not sure what can be done aside from documenting the need to call loop = asyncio.get_event_loop() in the child immediately after forking. -- ___

[issue22087] _UnixDefaultEventLoopPolicy should either create a new loop or explicilty fail when get_event_loop() is called from a multiprocessing child process

STINNER Victor added the comment: A simple pid check in the policy should be enough. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22087 ___

[issue22087] _UnixDefaultEventLoopPolicy should either create a new loop or explicilty fail when get_event_loop() is called from a multiprocessing child process

Dan O'Reilly added the comment: Hmm, I'm not sure what you mean. What check in the policy would prevent this issue you described in #21998?: import asyncio, os loop = asyncio.get_event_loop() pid = os.fork() if pid: print(parent, loop._csock.fileno(), loop._ssock.fileno()) else:

[issue22087] _UnixDefaultEventLoopPolicy should either create a new loop or explicilty fail when get_event_loop() is called from a multiprocessing child process

Changes by Dan O'Reilly oreil...@gmail.com: -- title: _UnixDefaultEventLoop policy should either create a new loop or explicilty fail when get_event_loop() is called from a multiprocessing child process - _UnixDefaultEventLoopPolicy should either create a new loop or explicilty fail

[issue22087] _UnixDefaultEventLoopPolicy should either create a new loop or explicilty fail when get_event_loop() is called from a multiprocessing child process

Changes by Dan O'Reilly oreil...@gmail.com: Removed file: http://bugs.python.org/file36116/handle_mp_unix.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22087 ___

[issue22087] _UnixDefaultEventLoopPolicy should either create a new loop or explicilty fail when get_event_loop() is called from a multiprocessing child process

Changes by Dan O'Reilly oreil...@gmail.com: Added file: http://bugs.python.org/file36118/handle_mp_unix.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22087 ___

[issue22087] _UnixDefaultEventLoopPolicy should either create a new loop or explicilty fail when get_event_loop() is called from a multiprocessing child process

Guido van Rossum added the comment: Good point. Asyncio definitely should not share event loops across forked processes. However, I don't like the dependency on multiprocessing (even though it's in the stdlib) -- can't the policy just use os.getpid()? Also, I've got a feeling that maybe the

[issue22087] _UnixDefaultEventLoopPolicy should either create a new loop or explicilty fail when get_event_loop() is called from a multiprocessing child process

Dan O'Reilly added the comment: Yep, agreed on both points. The latter suggestion also has the benefit of not requiring any test changes. Here's an updated patch. -- Added file: http://bugs.python.org/file36119/map_chunksize2.patch ___ Python

[issue22087] _UnixDefaultEventLoopPolicy should either create a new loop or explicilty fail when get_event_loop() is called from a multiprocessing child process

Guido van Rossum added the comment: I think there should still be a new unittest -- we're adding a behavior we're promising, so we should test it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22087