Re: [gentoo-portage-dev] EbuildProcess logs poll-error to already removed $T (on AIX)

[Zac Medico]

On 03/28/2011 07:01 PM, Perry Smith wrote:
> I did not 100% follow this.  In particular, I didn't see how we started talking about pty's.  But, since you are, I'll wade in.
>
> When the master side (the side that a daemon opens like telnetd) closes, the slave side gets the same treatment as if a modem hung up on a real tty.  This is a SIGHUP *and* any further writes will return EIO (5) and further reads return 0.  (All this is assuming CLOCAL is off.)
>
> I would not be surprised if the child process is receiving a SIGHUP if all the process session and controlling tty requirements have been met and the file descriptor is also selectable for POLLHUP and POLLERR.  I would peek inside the Python code because perhaps it is testing for POLLERR before it is testing for POLLHUP.  Or, perhaps it is not expecting the POLLERR at all (that is the 16384 value)

In our case, a subprocess is connected to the slave end of the pty, and
portage reads its output from the master end. With Linux (among other
kernels), after the subprocess closes the slave end, we typically
receive a POLLHUP event or else EIO from a read call. Apparently, Linux
(among other kernels) we never receive a POLLERR event here, but with
AIX we do.

> This should *not* be AIX specific but is actually POSIX standard.

When we receive POLLERR, we could try calling waitpid with WNOHANG on
the subprocess. If the process exits successfully at this point, then
it's probably safe to handle this case much like a POLLHUP even. For
this to work reliably, it seems like we will need to retry the waitpid
call in loop with some sleep calls, until the subprocess status becomes
available. If the status doesn't become available after a few seconds,
then we should probably try to kill the subprocess.
-- 
Thanks,
Zac