[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

A few random I/O proposals



   Date: Sat, 30 May 92 12:31:05 -0400
   From: david carlton <carlton@husc.harvard.edu>

   I don't like this so much.  The ideal way that output should work is
   for it to be unbuffered - buffering is really just a performance hack
   adopted out of necessity.  Given that, I think that implementations
   should be encouraged not to buffer output whenever it is reasonable to
   assume that the potential losses from not buffering outweight the
   gains from buffering.  In particular, I think that they should never
   buffer output that is sent to a terminal, irrespective of whether or
   not input is requested from that terminal.

Truly unbuffered I/O is not available on most systems.  On a truly
unbuffered line you would lose every character you didn't read in
time.  The time slice you get under most operating systems is much too
long to guarantee keeping up with a 9600 buad line.  The unbuffered
I/O you get in unix means that it isn't buffered by a utility routine
in the application program.  It is still buffered in the operating
system.

   With terminals, there is
   essentially no loss from not buffering output, since programs can
   generate unbuffered output faster than humans or terminals can handle.

You have this backwards.  There would be a very large performance
impact because you would be requiring your process to be running to
send each character.  Each character write would cause your process to
be swapped out if there were another process to run.  This would limit
you to about 60 cps on many systems.  This is below the 100 cps of a
9600 buad line (which can easily be acheived with buffering).

   And there are definite gains - I don't want to have to wait until a
   Scheme program has generated 8k of text before seeing any of it.
   Similarly, if a Scheme system is started up interactively, I don't
   think that output to the inital (current-output-port) should be
   buffered.  Implementors may also decide that output to pipes shouldn't
   be buffered.

You don't have to give up buffering in order to see output before the
buffer is full.  Posix fflush will do it.  Newline could additionally
be specified to fflush (at least to current-output-port).

I think the real root of the problem here is that read and write have
side-effects.  In order to have program semantics be clear, it is
neccessary to understand just when the side-effects take place.  There
is an unstated assumption that data side-effects take place before
the function performing them returns.  This is not the convention for
read and write and, as I stated above, the performance implications of
doing so are so severe that it shouldn't be.

(force-output <opt-port>) is a method for synchronizing with output
side-effects.  I think that the standard should be clear about when
read/write operations are acutally done since I can construct programs
whose behaviour is determined by it.  INPUT-READY? takes care of the
input side but there is currently nothing for output.