mike (06/29/82)
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,
-Mikeatbowler (06/29/82)
Having worked on I/O packages for several non-Unix environments,
I would like to share some observations.
1) Buffering pays off. You can do a lot of computation in the time
it takes the system to field 1 system call.
2) It is not a question of flushing stdout and stderr on a read from
stdin, but of flushing the corresponding output buffer(s) when reading
from a terminal, wheither it was opened as unit 1 or 9. To do this
you need to keep track of which units are TTY's, and which units
are the same TTY. Xerox's CP-5 used to supply a system call to
test this, but a little enginuity at open time will usually suffice.
3) You should arrange that different output units that share a tty,
share a buffer. I.e. stout and stderr normally would point at the
same buffer. That way messages appear in the order they are issued
in the program and not in the flush order.
4) The output buffer is flushed under the following situtations and
standard subroutines should be supplied for this
1) the output buffer is full
2) the buffer is being closed (usually wrapup)
3) a read was issued from a corresponding read unit
4) the program goes to sleep
(sleep for n seconds or sleep until time.. whatever the system has)
This is a situation where you supply a standard subroutine and
advertize it, instead of the one that does just the system call
5) The program calls another program
and waits for it.
i.e. i.e. the function 'system'jerry (06/30/82)
I agree that flushing of stdout and stderr should be tied to reading from
stdin. And that stdio should contain a general mechanism to tie
the flushing of one stream to reading from another.
But this should be based on the LOGIC of the program, not on
whether any of these is a tty or which is a tty.
Output intended for the tty may be filtered (e.g. I very
frequently set up "tee") before arriving there. If the output of
program is going to a pipe, there is no way to tell what its
ultimate destination is.
Jerry Schwarz -- eagle!jerry -- BTL Murray Hill -- (201) 582-5926