Re: Flushing libgfortran from C

[Janne Blomqvist <blomqvist dot janne at gmail dot com>]

On Thu, Mar 3, 2011 at 12:48, Tobias Burnus <burnus@net-b.de> wrote:
> On 03/03/2011 11:26 AM, N.M. Maclaren wrote:
>>
>> Er, no. ÂThat's stderr you are thinking of.
>
> No, I am actually thinking of stdout (and stderr), but I am thinking of a
> different buffering.
>
> There is some internal buffering in libgfortran, which is needed if one
> decides to all of a sudden to change items in the current record (T edit
> descriptors), but which is also used for performance reasons. This
> libgfortran internal buffering is turned off for stdout, stderr, stdin,
> sockets (fifo), and pipes - and if one sets an environement variable for all
> units. Thus, for those units, the libgfortran's buffer is flushed after each
> I/O transfer statement. However, then the next buffer kicks in: The one of
> the libc library, which can be flushed by fflush. And next and last
> accessible one is the operating system's I/O buffering, which can by flushed
> by fsync.

Close, but not quite.

1) For formatted IO, libgfortran has an internal per-statement buffer
(the fbuf_* stuff) which is needed e.g. to handle TL edit descriptors
on unseekable devices such as terminals. This cannot be turned off,
but it is flushed for every IO statement (the exception is
advance='no' where the entire buffer is not flushed).

2) Then there is a traditional IO buffering layer in order to reduce
syscall overhead (the buf_* stuff in unix.c). This is enabled only for
regular files and for block special files, but can be turned off with
an environment variable.

3) As gfortran does not use C stdio but rather the unbuffered POSIX IO
(read(2), write(2), lseek(), ftruncate() and so on), gfortran itself
never uses the libc stdio buffering. Hence calling fflush() is per se
not needed for correctness, however we still call fflush in a few
places in order to help badly written programs which mix Fortran and
stdio IO on the same files.

4) Yes, there is the OS IO buffers, and then disk drives and/or disk
controllers often have their own write-back caches as well. A
competent implementation of the fsync() syscall should make sure these
are flushed to permanent storage (permanent here including battery
backed write caches), but while that's an important issue on its own,
it's not really related to this issue.


-- 
Janne Blomqvist