Milko Krachounov <pyt...@milko.3mhz.net> added the comment: I created another patch that attempts to create the pipes atomically.
On GNU/Linux, if pipe2 is available, it uses it to create the pipes, and there is no race. On other POSIX platforms, pipe and fcntl are called without releasing the GIL - relying on the fact that _posixsubprocess.fork_exec doesn't release the GIL either, so the two can't run at the same time (bonus: os.fork doesn't release the GIL either). I can't reproduce neither issue 7213 nor issue 2320 with either implementation, so the patch seems to fix them. Issues: 1. If the _posixsubprocess module isn't compiled, the race still exists (well, without it subprocess isn't safe to use with threads anyway). 2. On GNU/Linux systems where glibc was compiled with kernel headers >=2.6.27, but the running kernel is <2.6.27, the subprocess module won't work. (There should be a fix for that?) 3. I have no way to tell that the non-Linux implementation works for sure. I've been running it in an endless loop, and so far there have been no hangs (*), but that doesn't mean that it doesn't have a rare race that's beyond my comprehension. With pipe2() you can be certain, but I have my doubts about the other implementation. All unit tests seem to pass. (*) Actually, I *thought* it hang on my first attempt, but I interrupted the process too soon to tell for sure. No hangs after that. :( ---------- Added file: http://bugs.python.org/file20005/subprocess-cloexec-atomic-py3k.patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7213> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
