Re: hangup in close(2) after posix_openpt(3)

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>>> 17171;
>>> [...] 12534 [...]
>> Possibly, but, don't forget, both 17171 and 12534 are about unread
>> slave->master data.  This hang is about unread master->slave data
>> (or, at least, that's what it looks like to me).
> The report said the problem went away when they disabled echo, and
> the echo would be slave->master data.

Oh, well spotted.  Thank you.

> Now, I think the argument could be made that the 7.0 behavior is
> actually correct, that the close() *should* block (interruptibly)
> until the last echoed character has been read by the master,

Hm.  I think I disagree.  I think the slave close should succeed more
or less immediately, with the data should be buffered in the pty driver
until either it's read from the master or until the master side is also
closed.

I think an argument could be made that _all_ slave->master data not
promptly read by the master should be dropped, since that's how real
serial ports work - if you're not paying attention when a character
arrives on the wire, it's lost.  If you want to argue that the
receiving computer normally has buffering in its tty driver, then I
reply that in that model, pseudo-ttys should be pairs of slaves, with
no masters at all.

But I also think that buffering and the current master/slave model are
reasonable deviations from faithful emulation for the sake of
usability.

> In the case of an exiting process we don't have much of a choice - we
> need something like the -current 17171/12534 fix because if the
> output data aren't discarded, the slave process will never die.

To the extent that this is true, it's true only because the pty driver
makes it so.  (IOW: it's fixable.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B