any harm in allowing only ctrl-Q to restart output?

[Guy Harris]

> Whether interrupt should unstall output depends on whether one
> views DC3/DC1 flow control as user-controlled or as hardware-
> controlled.  It is more important to get the hardware working
> right, to avoid hung terminals...

Bravo!  (Although Bravo probably didn't have this problem, since
if the CPU can push the bit map directly there's no worry about flow
control... :-))  VT100s are notorious for requiring *very* strict XON/XOFF
handling, especially in smooth scroll mode.

> There are UNIX terminal drivers that will continue dumping a lot
> of characters to a terminal that has tried to stall by sending a
> DC3.  The worst offenders are probably those that insist on using
> input silo level alarms.  Such terminal drivers are broken and
> should be fixed.  (This is possible, since there are also UNIX
> terminal drivers that do this right.)

To be precise, the V7 DH11 driver adaptively set the silo alarm level based
on how full the silo was when it was last drained.  That code pretty much
dropped in to the 4.1cBSD DH and DZ drivers.  (I remember reading that
the RSX-11D/IAS DH and DZ drivers also set the silo alarm level adaptively.)

We found that it didn't clear up all the occasional glitches we saw,
however; we later profiled the system using the System III/System V
kernel profiler (which doesn't do a graph profile like the 4.2BSD profiler
but which is claimed to consume little overhead, can be turned on and off
on a production system, and drops into the 4.2 kernel with little work)
modified only to profile routines running with an interrupt level greater
than spl5() level, and found that the system was spending quite a bit of
time in interrupt service routines *et al* at elevated priority (if I
remember correctly, the disk driver "hp.c" was one of the major culprits) -
enough time to delay the interrupt that tells the host that an XOFF came
in until after it was too late.  The DEC operating systems keep the time
spent at elevated priority within ISRs as low as possible; this improves
real-time response, and could be applied to UNIX.  (Does anybody know
if any of the DEC OSes have XON/XOFF trouble with smooth-scrolling VT100s
at high baud rates?  We saw the most trouble at 19200 baud, which is not
supported by a standard DH and is not supported by all DZs either.)

> If your users can't be taught that interrupt doesn't automatically
> unstall their terminal, then you have other worse problems to
> worry about!  Try taping "TYPE CTRL-Q" notes on their terminals.

DEC's word processors were built out of VT52s, and later VT100s, and PDP-8s;
I remember one of their manuals telling the user that if the system doesn't
seem to be responding to their typing, they should hold down the button
labelled CTRL and typing the Q key...  (Which was one reason I insisted that
the custom firmware in the terminals we offer with our office automation systems
could be put in a mode which prevented the user from typing control keys.)

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy