This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author milko.krachounov
Recipients Giovanni.Bajo, georg.brandl, gregory.p.smith, milko.krachounov, ned.deily, paul.moore
Date 2010-12-11.01:32:58
SpamBayes Score 6.97285e-10
Marked as misclassified No
Message-id <>
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.

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. :(
Date User Action Args
2010-12-11 01:33:00milko.krachounovsetrecipients: + milko.krachounov, georg.brandl, gregory.p.smith, paul.moore, ned.deily, Giovanni.Bajo
2010-12-11 01:33:00milko.krachounovsetmessageid: <>
2010-12-11 01:32:59milko.krachounovlinkissue7213 messages
2010-12-11 01:32:59milko.krachounovcreate