[Other proposals]
Problem
The standard does not specify whether buffering is allowed for words
dealing with the user input and output devices, and the file
words. The existence of FLUSH-FILE indicates that buffering is allowed
to some extent.
Proposal
No buffering is allowed for the user input device. No buffering is on
the user output device, if it is a terminal. Buffering is allowed for
the user output device, if it is no terminal (e.g., a file), and for
the file wordset. The amount of buffering is system-defined.
OUTFILE-ID ( -- file-id ) file-ext
the file-id for the current user output device
Remarks
Allowing buffering for non-terminal user output device may increase
the performance for filters.
Flushing the user output device can be achieved with
OUTFILE-ID FLUSH-FILE ...
Experience
Gforth <=0.3.0 used no buffering for KEY, line buffering for
outputting to a terminal, and block buffering for outputting on
non-terminals. Several users complained about the buffering for the
user output device (they used a terminal), so starting with 0.4.0 we
use no buffering for the user output device if it is a
terminal. Nobody has complained about the file buffering.
Gforth has implemented OUTFILE-ID since 0.2, and it is in use
(mainly internally).
Experiments with a filter we had on Gforth under Linux showed no
significant performance advantage for buffering the user output
device. We should repeat this experiment with a more I/O-intensive
filter (the one we measured produced only 94KB of output).
Another experiment with Gforth under Linux-Alpha resulted in a
worst-case slow-down factor of 25 for turning off buffering. The
benchmark used in this experiment was:
: foo
10000000 0 +do
[char] x emit
loop ;
Anton Ertl