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

[Andreas Gustafsson <gson%gson.org@localhost>]

Mouse wrote:
> > 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.

That's an interesting idea, but I don't think this is really a pty
issue.  The same question arises with real serial port ttys - if you
still have buffered output data when you call close(), what should
happen?

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

Only on serial ports with no flow control.  I think a serial port with
flow control is the more useful model to emulate.

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

It may be fixable for ptys, but we still need a way to ensure that
processes writing to real serial ports blocked by hardware flow
control can be killed.  That is the specific problem the timeout code
in -current is intended to fix.
-- 
Andreas Gustafsson, gson%gson.org@localhost