Re: n_tty: Check the other end of pty pair before returning EAGAIN on a read()

[Marc Aurele La France <tsi@tuyoix.net>]

On Fri, 18 Dec 2015, Marc Aurele La France wrote:
> On Fri, 18 Dec 2015, Peter Hurley wrote:
>> On 12/18/2015 06:26 AM, Marc Aurele La France wrote:
>>> On Fri, 11 Dec 2015, Peter Hurley wrote:
>>>> On 12/11/2015 05:37 AM, Marc Aurele La France wrote:

>>>>> I am not asking to read data before it has been produced.  I am puzzled
>>>>> that despite knowing that the data exists, I can now be lied to when I
>>>>> try to retrieve it, when I wasn't before.  We are talking about what is
>>>>> essentially a two-way pipe, not some network or serial connection with
>>>>> transmission delays userland has long experience in dealing with.

>>>>> These previously internal additional delays, that are now exposed to
>>>>> userland, are simply an implementation detail that userland did not,
>>>>> and should not, need to worry about.

>>>> Your mental model is that pseudo-terminals are a synchronous pipe, which
>>>> is not true.

>>>> But this argument is pointless because the regression needs to be fixed
>>>> regardless of the merits.

>>> Fair enough.

>>> Anything new on this?

>> It's on my todo list.

>> While considering this issue further, I was curious what ssh does
>> regarding the entire foreground process group and its output?

>> If ssh only knows that the child has terminated, how does it wait
>> for the rest of the foreground process group's output since those
>> processes may not yet have received their SIGHUP/SIGCONT signals
>> yet?

> sshd cannot know about the termination of any process other than the
> session leader because any of the session leader's children are
> re-parented to init.  The idea is to, at minimum, collect any output the
> session leader might have left behind.  Yes, this could entail also
> collecting output from its children that might have squeaked in, but
> that's gravy that can't be avoided.

> This situation is much simpler on the *BSDs.  There, both ends of the
> pty pair are, in effect, completely closed after disassociation of either
> end, preventing (with EIO) any further output (but still allowing data
> already collected to be read, after which an EIO occurs).  It's
> unfortunate System V variants don't do this, but that's crying over spilt
> milk.

Anything more on this?

Thanks.

Marc.