Message200553
| Author |
neologix |
| Recipients |
David.Edelsohn, db3l, gvanrossum, larry, ncoghlan, neologix, pitrou, python-dev, skrah |
| Date |
2013年10月20日.08:52:08 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<CAH_1eM1pBbKXx+9xU1VxPy+s3UnHT=CrA=+SpC9n36Bid0S_ZQ@mail.gmail.com> |
| In-reply-to |
<CAP7+vJL3iddpA5R_r8E3s5CCRLzjvOmvZcGMBavUuRu9dqYO_w@mail.gmail.com> |
| Content |
> Guido van Rossum added the comment:
>
>> Apparently, the stdout pipe was closed by the parent process
>
> Could it be that selecting for *read* on the *write* end of a pipe is
> always ready?
That's exactly what I was thinking when I read the code below: that's
definitely a possibility on AIX.
> In _UnixWritePipeTransport there's a read handler that
> immediately closes the pipe as soon as it called. I vaguely remember a
> discussion on python-tulip that this might be Linux-specific behavior. (The
> reason is that otherwise you can't find out whether the other end was
> closed unless you attempt to write to the pipe.)
Normally, if the pipe is closed, it should be reported by a POLLHUP/write ready.
Then you only consider it closed when write fails with EPIPE. |
|