Re: Flushing libgfortran from C

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

On Thu, Mar 3, 2011 at 13:44, Janne Blomqvist <blomqvist.janne@gmail.com> wrote:
> 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.

And, this is the buffer which is flushed by the FLUSH
statement/subroutine/function.

> 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
>



-- 
Janne Blomqvist