On 03/28/2011 08:07 PM, Perry Smith wrote:
> 
> On Mar 28, 2011, at 9:49 PM, Zac Medico wrote:
> 
>> 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.
> 
> I want to make sure you typed what you meant to type because it wasn't what I 
> was expecting.
> 
> Does the slave close first or the master?  Or, I suppose, more importantly, 
> which side (the master or the slave) is getting the POLLERR?

The slave does. This code works the same way as the "script" program
which is used to capture the output of a terminal session that is
attached to the slave end of a pty. Eventually, the subprocess that's
attached to the slave end exits, and that's presumably when the master
end receives the POLLERR event.

I should note that I assume that the POLLERR event occurs when the slave
end is closed, since the user has not reported any loss of subprocess
output. If the POLLERR event occurred before that, then output from the
subprocess would be lost.
-- 
Thanks,
Zac

Reply via email to