Message123763
| 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.9728523e-10 |
| Marked as misclassified |
No |
| Message-id |
<1292031180.77.0.055060531128.issue7213@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
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. :( |
|