Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!rlgvax!guy From: guy@rlgvax.UUCP (Guy Harris) Newsgroups: net.unix-wizards,net.dcom Subject: Re: any harm in allowing only ctrl-Q to restart output? Message-ID: <319@rlgvax.UUCP> Date: Wed, 2-Jan-85 18:07:44 EST Article-I.D.: rlgvax.319 Posted: Wed Jan 2 18:07:44 1985 Date-Received: Fri, 4-Jan-85 00:41:18 EST References: <247@lsuc.UUCP> <104@redwood.UUCP> Organization: CCI Office Systems Group, Reston, VA Lines: 19 Xref: watmath net.unix-wizards:11323 net.dcom:759 > The only thing you want to make sure of is that even if output is stopped, > the interrupt and quit functions must turn it back on (when the terminal > is not in "raw" mode). Well, err, umm... System III did this, but System V doesn't, and 4.xBSD never did. I don't know about TOPS-[12]0 or VMS or any DEC operating systems. I suspect they don't, because it gives VT100s the ****fits. The VT100 has a very small buffer between the comm line and the screen updating code, so it demands *very* strict XON/XOFF flow control, especially in smooth-scroll mode. I have seen a fair amount of output get scrambled by hitting the interrupt key in the middle of output; it stopped happening when we had interrupt and quit not affect the flow control state. (UNIX can cause XON/XOFF problems even when working correctly; its habit of surrounding every critical region with spl5() (or whatever) and running all interrupt service routines at interrupt priority all the time means it doesn't always respond to an XOFF in time.) Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy