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

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

>> I think the slave close should succeed more or less immediately,
>> with the data should be buffered in the pty driver [...]
> 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?

IMO?  close() should succeed and the data in the tty output buffer
should sit there until it's explicitly flushed (eg TCSAFLUSH) or flow
control is released and it drains.  (To keep buffers from expanding
indefniitely, I would start blocking (or failing if O_NONBLOCK) writes
when the buffers get full.)

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

Gotcha.  But I still think it's the wrong fix; I think the right fix is
to fix the generic tty layer (as used by both pty slaves and real
serial ports) so that close doesn't block for queued data to drain.

/~\ 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