> > 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.