chris@mimsy.UUCP (Chris Torek) (11/13/88)
In article <773@wsccs.UUCP> terry@wsccs.UUCP (Every system needs one) writes: >Another reason to avoid flow control is the fact that IXON is handled at >the kernel level. What this means to you is that if you get XOFFed by the >modem, you will hang in your read or write until you receive an XON. The >period of time you wait depends only on how long the interval is before >you get an XON. Since you are hanging in the kernel, any signals you have >used to interrupt your read will be queued until that time. If, then, you >receive an XOFF and the line drops, you are stuck. Forever. The situation described above is factual, but the explanation is not. If the output queue is full---which will certainly happen after stopping for XOFF---writes will indeed block, but they will do so interruptibly. Likewise, if the input queue is empty, reads will block, but, again, interruptibly. 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. A number of kernels get this wrong, various BSD implementations included. Note, though, that `giving up' will put some terminals into a confused state. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
guy@auspex.UUCP (Guy Harris) (11/17/88)
>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).