Guido van Rossum added the comment: > > 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.
David confirmed that it is the _read_ready() that closes the pipe prematurely. (Thanks David!) > > 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. That's no good though unless the app wants to write -- the write end also reports write ready when it is empty (or nearly so), so this won't help an app that has done all the writing it wants to (at least for a while) but still wants to be notified when the other end has closed it. Now, there are other indications, such as the pipe in the other direction giving an EOF, or the process exiting, but sometimes neither of those happens, and then we're stuck. I guess we'll have to write platform-dependent code and make this an optional feature. (Essentially, on platforms like AIX, for a write-pipe, connection_lost() won't be called unless you try to write some more bytes to it.) I do believe that so far this problem only occurs on AIX so I am tempted to make it an explicit test for AIX -- if it's AIX, don't register the _read_ready handler. We'll also have to skip or adjust one or two tests that will fail if this feature is missing. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19293> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com