Buffering clarification

[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