Xref: utzoo comp.dcom.modems:2967 comp.unix.wizards:12488
Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.dcom.modems,comp.unix.wizards
Subject: Re: xon/xoff, signals, hangup
Message-ID: <460@auspex.UUCP>
Date: 16 Nov 88 22:35:54 GMT
References: <260@eda.com> <773@wsccs.UUCP> <14526@mimsy.UUCP>
Reply-To: guy@auspex.UUCP (Guy Harris)
Followup-To: comp.unix.wizards
Organization: Auspex Systems, Santa Clara
Lines: 29

>When you close the line (e.g., at exit from SIGHUP), the kernel
>(correctly) waits for the output to drain.  It *should* give up
>after a `reasonable' timeout, on the assumption that output never
>will drain.

Define "reasonable".  What if the line is going to a printer, and it
runs out of paper?  It could be a while before those last few characters
get transmitted....

>A number of kernels get this wrong, various BSD implementations
>included.  Note, though, that `giving up' will put some terminals
>into a confused state.

The S5R3 streams code "gets it right" in the sense that it will time out
eventually; unfortunately, in addition to flushing data queued for a
streams module when it gets tired of waiting for that module to drain
its queue, it also gets rid of the module - which means that unless the
driver handles XON/XOFF, you lose flow control at some point, which
will, indeed, put some terminals in a confused state.

The line discipline-based S5 tty drivers don't time out, but they will
un-stop XOFFed output when the line is closed; this will also put some
terminals in a confused state....

Unfortunately, I'm not sure there's a single way of getting it right. 
Printers, plotters, etc. should be prepared to wait forever; terminals
on which people are logged in, or dial-out lines, should perhaps give up
eventually (although perhaps carrier going away could be the signal for
this).