[net.unix-wizards] STDIO on TTYs: Clarification and Repeat of Question

Michael@sri-unix (07/30/82)

Date:     28 Jun 82 17:05:11-EDT (Mon)
My own opinion is that the present STDIO design SUCKS with respect to
handling I/O to terminals.  Using STDIO represents a giant step BACKWARDS
from the V6 getc/putc when talking to terminals, as unbuffered terminal
I/O is a machine gobbling waste.

ASSERTION 1:  The STDIO package can make whatever buffering decisions it
wants to, without affecting portability, as long as the user interface
looks the same at the top level, and flushes are done before any inputs.

ASSERTION 2:  Output to STDOUT and STDERR ought to be buffered automatically
by STDIO.  If a flush occurs under the following conditions, things should
still work right:

*)  If a newline is printed on STDOUT or STDERR, a flush occurs.

*)  If a SYS-READ is executed within the STDIO code for STDIN, a flush of
    STDOUT and STDERR should be performed.

DISCUSSION:  The first point above provides for the user seeing everything
except for a fragment of the last line being composed in the buffer, should
the program unexpectedly fault or die.  The second point provides for
prompt strings not terminated by a newline to be printed out before
doing the SYS-read call to get the reply.  In the worst case, printing
nothing but newlines, this is no worse than before.  For an average
output line of 60 characters, this represents a savings of 60X in
sys-call costs.

If the program is doing interactive I/O on files other than STDIN and
STDOUT,  then it already has to make provisions for buffer flushing, and
that will not change.  While I do not consider myself a "bit counter" or
an "efficiency fiend", grossly incorrect choices of algorithm really
tick me off, and just because something may be "Bell Code" does not mean
it is sacred.

I had heard that somebody (Berkeley?  Perdue?) had addressed this problem,
and produced a fix along the lines of what I mentioned above.  Does anybody
know if this has been done?  If not, we will do it and post the fixes
to the list.
					Smoldering,
					 -Mike

ecn-pa.scott (07/30/82)

It's NOT "Perdue", it's "Purdue"!!!!!  Perdue processes
chickens.  Purdue processes students.

	Scott Deerwester
	P*U*rdue University Libraries

mark (07/30/82)

Congratulations, Mike, you've just reinvented 4.1BSD!  Obviously you're
running V7 on an 11, which is 4 years old.  Stdio is a good design, it's
done wonders for portability of C programs.  It's just that the 1978
decisions made in the initial implementation were tuned for 300 baud
hard copy terminals.

sdyer@BBN-UNIX@sri-unix (08/13/82)

From: Steve Dyer <sdyer@BBN-UNIX>
Date: 29 Jul 1982 23:45:29 EDT (Thursday)
Berkeley first fixed stdio to perform the buffering scheme that you
propose.  We have also incorporated a similar scheme here at BBN.
(It was before I arrived, so I don't know whether it was an original
piece or derived from Berkeley.)

Everything you say is true regarding STDIO efficiency, ESPECIALLY
when it comes to ARPAnet connections.

/Steve Dyer