Path: utzoo!utgpu!watmath!clyde!att!gargoyle!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.dcom.modems
Subject: xon/xoff, signals, hangup (was Telebit Setup script)
Message-ID: <14526@mimsy.UUCP>
Date: 13 Nov 88 10:08:05 GMT
References: <260@eda.com> <773@wsccs.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 22

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