Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!nntp-read!jbw From: jbw@bucsf.bu.edu (Joe Wells) Newsgroups: comp.emacs Subject: Re: Flow control Message-ID: Date: 1 Dec 90 10:11:09 GMT References: <1990Nov17.203241.16722@athena.mit.edu> Sender: news@bu.edu.bu.edu Organization: Boston University Computer Science Department Lines: 28 In-reply-to: chuck@mitlns.mit.edu's message of 17 Nov 90 20:08:50 GMT In article <1990Nov17.203241.16722@athena.mit.edu> chuck@mitlns.mit.edu writes: I've read RMS's notes on control-s/q flow control and I'm curious about it. I don't work on Unix machines, and I wonder how they handle flow control. Somewhere I got the impression that they did it by setting up timings of operations and sending out enough null codes after each command to ensure that the terminal has time to complete the operation before starting the next (padding). If this is true I don't see how RMS can reasonably claim that it is better than Xon/Xoff processing. This is not the same as saying that characters other than Q and S should of been used which may be a valid point if you have been using them for something else. The problem with XON/XOFF flow control is that it is in-band instead of out-of-band. Sending NULs is also an in-band method of flow control. I interpret RMS's statement as being opposed to in-band flow control. In general, any out-of-band method is superior. However, out-of-band methods are more complicated to set up, and more politically difficult to put into place. For the RS232 protocol, the DTR and DSR lines are already there. Unfortunately, these signals aren't currently propagated across modem-to-modem connections, and thus can't always be used for flow control. -- Joe Wells Brought to you by Super Global Mega Corp .com