Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!ames!oliveb!jerry
From: jerry@oliveb.UUCP
Newsgroups: comp.sources.d,comp.terminals,comp.emacs
Subject: Re: VT100's keeping up at high baud rates
Message-ID: <1439@oliveb.UUCP>
Date: Wed, 17-Jun-87 15:25:16 EDT
Article-I.D.: oliveb.1439
Posted: Wed Jun 17 15:25:16 1987
Date-Received: Fri, 19-Jun-87 01:19:10 EDT
References: <5490@think.UUCP>
Reply-To: jerry@oliveb.UUCP (Jerry F Aguirre)
Organization: Olivetti ATC; Cupertino, Ca
Lines: 25
Xref: utgpu comp.sources.d:796 comp.terminals:286 comp.emacs:1029

In article <5490@think.UUCP> rlk@THINK.COM writes:
>It's amazing how easy it is to avoid externally-visible flow control
>if you really try.  The answer is buffering.  Several years ago, I was

Nothing less than an infinite amount of buffering will guarante that
flow control is never needed.  (Assuming that the terminal can't process
the characters at full speed.)

For any amount of buffering you can devise a sequence of characters, say
insert line at the top of the screen, and repeat them continuously.
This will eventually fill up the buffer and either drop characters or
require flow control.

Granted that most applications do other things besides scrolling the
screen and this will usually allow the terminal to catch up.  Also they
seldom send continuous data without any pauses for input.  But it
sometimes does happen.

Besides, large input buffers present their own problems.  Have you ever
tried to pause a display that has lots of buffering?  If you signal the
host to stop sending then what you want to see can scroll off the screen
because of the local buffer.  Most such terminals resort to a local
pause instead of depending on the host to pause output.  But, unless you
also signal the host, your buffer will fill and overflow.  So, you still
have to have some kind of flow control.