STINNER Victor <vstin...@python.org> added the comment:
Eryk Sun > Alternatively, instead of special casing the file type and spinning on > PeekNamedPipe, the workaround could be based on a multiple-object wait that > includes the child process handle. (...) Well, maybe we could do something to enhance regrtest, but the initial bug described in this issue should be fixed by my commit de2d9eed8bc628533e1628b843cc4c7a5010f6e5 which added a timeout to the second Popen.communicate() call, but also to the Popen.wait() call (moreover, "with popen:" is no longer used). Both functions use a timeout of 30 seconds which should be short enough to prevent the main regrtest process to block for hours. When a process is killed and stdout.read() never completes, the stdout.read() thread will likely never completes. But I consider that it's a separated bug that should be addressed in a separated issue. Jeremy Kloth: > In short, the PR doesn't change the problem. The regrtest main will wait > indefinitely on the successfully killed process. Again, my commit de2d9eed8bc628533e1628b843cc4c7a5010f6e5 should fix this behavior. -- I'm not sure why test_regrtest.test_multiprocessing_timeout() failed with a timeout on x86 Windows7 3.x; see msg350060. Maybe my commit 767434c39c8f3c6a8af1b3282d8382ccf809fe21 will give more information if the test fails again on this buildbot. I will backport regrtest changes to other 3.7 and 3.8 branches. I wait a few more days to see if buildbots are stable with latest regrtest changes. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue37531> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
