Path: utzoo!attcan!uunet!husc6!mailrus!nrl-cmf!ames!oliveb!sun!gorodish!guy From: guy@gorodish.Sun.COM (Guy Harris) Newsgroups: comp.unix.questions Subject: Re: VT100 terminfo problem Message-ID: <68858@sun.uucp> Date: 19 Sep 88 04:03:19 GMT References: <3340@dunkshot.mips.COM> <8521@smoke.ARPA> <68816@sun.uucp> <8527@smoke.ARPA> Sender: news@sun.uucp Lines: 32 > >The *ONLY* time "raw" mode should be used for "full-screen" interactive > >applications are those times when: > Add another one: > 5) keys must not generate signals. And another one: 6) the application must require neither parity generation on output nor any other special output processing (such as tab expansion, conversion of '\n' to CR-LF, etc.). > >If it spent enough time at that level, and if the serial port was run at a > >high-enough baud rate, it is conceivable that the driver might not see the > >interrupt indicating that the ^S came in, and thus might not see the ^S > >itself, in time to stop output before the VT100's buffer overran. > This problem can really occur only if the tty port output is done > in large chunks, for example via DMA, and no provision has been made > for incoming tty port input to be immediately processed and the DMA > aborted when a DC3 is seen. I've seen a botch like this, by the way, > but since the vendor fixed their hardware, firmware, and software to > solve the problem I don't think I need to say who it was. Well, maybe. I no longer remember whether the VAX in question had DZs (with no DMA output) or DHs; offhand, it seems that if it had DZs the problem I cited wouldn't occur (since output is also interrupt-driven, and if the input interrupt signalling the arrival of the ^S were held off, the output interrupt telling the host to send the next character would also be held off), but if it had DHs the problem could occur (since DHs did have DMA output, and since the hardware didn't recognize ^S and stop immediately - that was up to the software).