[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 should detect the fork and handle the fork directly. -- ___ 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
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: http://bugs.python.org/file36134/handle_mp_unix_with_test.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
[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. -- ___ 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
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: print(child, loop._csock.fileno(), loop._ssock.fileno()) Output: --- parent 6 5 child 6 5 -- ___ 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
[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 when get_event_loop() is called from a multiprocessing child process ___ 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
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 pid should be part of the policy state instead of the loop state? The policy could just reset self._local when the pid doesn't match. -- ___ 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
[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 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
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
