Flushing libgfortran from C

[Mark W. Krentel]

Let me just check my understanding here.  In (2) below, gfortran
implements its own buffering, similar but separate to stdio?
Is that right?  I guess that's why fflush doesn't help.

And one can force a flush with  _gfortran_flush_i4 (NULL);
Is that right?

And just to be clear, the _exit() is deep within the bowels of Gasnet.
This seems to vary by conduit.  We've never seen this problem with
portals, infiniband, udp.

Thanks,

--Mark


Janne Blomqvist wrote:
> 
> 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.
> 
>