[Patch, Fortran ] PR 50016: Slow Fortran I/O on Windows and flushing/_commit
Mon Oct 17 13:25:00 GMT 2011
This patch adds a call to _commit() on _WIN32 for the FLUSH subroutine
and the FLUSH statement. It removes the _commit from gfortran's buf_flush.
* gfortran internally buffers the I/O, but it calls the nonbuffering
open/write/read functions (and not, e.g., fopen/fwrite/fread). On
Unix/Darwin/Linux system, the changes become immediately visible to all
processes after a "write()".
* On Windows, there seems to be a file-descriptor specific system buffer
such that the data only becomes available to other processes after
either a "_commit" or after closing the file.
* The Windows _commit() is a combination of a (system) buffer flush - as
a "write()" already implies on POSIX systems, but it also ensures that
the data ends up on the disk, which on POSIX systems is done via fsync().
Currently, _commit() is also called for the internal buf_flush, which
can happen very often and thus delays the I/O a lot (cf. PR 50016). With
this patch, it is only called when the user explicitly called FLUSH().
Contrary to non-_WIN32 systems, this also flushes to the hard disk,
which causes some slow down. However, as the user (should) only rarely
call the function, it should not pose a real performance issue.
The patch should ensure that the values can be read via other
file-descriptors within the same program or from other programs; on the
same time, it prevents excessive _commit() calling as it is done with
the current code.
An alternative would be not to call _commit() at all, leaving it to the
user. That would match the fsync() result on POSIX systems, but I think
having a file not available in the current status for other processes
causes more confusion that it helps. Thus, I think for FLUSH, one should
really make sure other processes get the right data.
The patch was build and regtested on x86-64-linux (where it should be a
OK for the trunk?
Can someone test it on MinGW/MinGW-64?
PS: For the discussion, see
PPS: I regard this patch as rather independent of INQUIRE even if the
issue first occurred with INQUIRE (PR 44698). Thus, it is independent
from whether one calls "stat()" for an open file or whether one uses a
different method like seek(SEEK_END) + tell() to obtain the file size.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3450 bytes
Desc: not available
More information about the Gcc-patches