Message142485
| Author |
neologix |
| Recipients |
Ben.Wolfson, idank, neologix |
| Date |
2011年08月19日.18:15:07 |
| SpamBayes Score |
4.4977781e-07 |
| Marked as misclassified |
No |
| Message-id |
<CAH_1eM11j=j=cK9nKhBuPmCGOAE+t4=zkNqi_8UU7+h=RiSU=w@mail.gmail.com> |
| In-reply-to |
<1313772112.7.0.669304302842.issue12786@psf.upfronthosting.co.za> |
| Content |
Hello Idan,
> The following program hangs on Debian
Debian is a good choice :-)
Concerning your example, it hangs is because the file descriptor used
to communicate with proc1 is inherited when proc2 is created (FDs are
inherited upon fork by default): thus, when you call
proc1.stdin.close(), `cat` doesn't receive EOF on read(0), and remains
stuck.
If you close proc2's stdin and wait it first, then you don't have this problem:
- because it's been created after proc1, its stdin FD has not been inherited
- when you call proc2.stdin.close(), `cat` receives EOF from read(0), and exits
There are two reasons while it doesn't hang on Python 3.x:
1) it uses close_fds=True by default
2) it sets the pipe FDs CLOEXEC, so that they're closed when cat is `executed`
Try with
"""
proc1 = subprocess.Popen(['cat'], stdin=subprocess.PIPE)
proc2 = subprocess.Popen(['cat'], stdin=subprocess.PIPE, close_fds=True)
proc1.stdin.close()
proc1.wait()
"""
And you'll be fine.
We can't make the change 1) in 2.7, because that's a behavior change.
We could however set the FDs used to communicate with the children CLOEXEC.
I'll work on a patch for 2.7 (but it won't be thread-safe, because
pipe2 is not exposed and there's no _posixsubprocess.c like in 3.x). |
|