When testing a patch for bug 591760 that mimics asyncio behavior by raising "RuntimeError: This event loop is already running" when event loop recursion occurs, I found this case: File "pym/_emerge/SpawnProcess.py", line 174, in _pipe_logger_exit self.wait() File "pym/_emerge/AsynchronousTask.py", line 54, in wait self._wait() File "pym/_emerge/SubProcess.py", line 100, in _wait self._waitpid_loop() File "pym/_emerge/SpawnProcess.py", line 177, in _waitpid_loop SubProcess._waitpid_loop(self) File "pym/_emerge/SubProcess.py", line 109, in _waitpid_loop self.scheduler.iteration() File "pym/portage/util/_eventloop/EventLoop.py", line 240, in iteration raise RuntimeError("This event loop is already running") RuntimeError: This event loop is already running SpawnProcess._pipe_logger_exit method calls self.wait() before the process exit status has become available, ultimately triggering recursion in the SubProcess._waitpid_loop method. It's possible for this sort of recursion to cause the recursion depth limit to be exceeded, like in bug 402335. The solution is to make SpawnProcess._pipe_logger_exit use child_watch_add trigger an asynchronous call to self.wait().
Patch sent for review: https://archives.gentoo.org/gentoo-portage-dev/message/54c695d6fcd7a62563bc6183827422d0 https://github.com/gentoo/portage/pull/150
This is in the master branch: https://gitweb.gentoo.org/proj/portage.git/commit/?id=eaf22a6d88ad8e0b7a3a1e21f3234c6b7037018a
Fixed in 2.3.6.
