STINNER Victor added the comment: I pushed a change based on multiprocessing_no_close_fd.patch. I changed multiprocessing.util._close_stdin() to try to replace sys.stdin with os.devnull even if stdin.close() raised an exception. Since stdin is read-only, I don't expect an exception on stdin.close(), but it's just in case :-) What do you think? Is it better to keep stdin if stdin.close() raises an exception?
I hate having to push changes without careful review. I wanted to fix buildbots as soon as possible. I'm working hard since 1 week to fix all random bugs on buildbots, so it's annoying when *all* buildbots are red :-/ I will read again the change later, but IMHO the approach is the good one. Python initialization also creates files (stdin, stdout, stderr) with closefd=False. The change should be backported to Python 3.5. I'm waiting for buildbots and I have to read again the change later. Note: It looks like all ResourceWarning of unit tests are now fixed. The following change succeed: ./python -Werror -m test -j0 test_multiprocessing_fork.py test_multiprocessing_forkserver.py test_multiprocessing_spawn.py test_multiprocessing_main_handling.py ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25654> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
