[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: hangup in close(2) after posix_openpt(3)
> > 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
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
> 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
Main Index |
Thread Index |