[Patch, Fortran ] PR 50016: Slow Fortran I/O on Windows and flushing/_commit

Tobias Burnus burnus@net-b.de
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...
Name: io_commit.diff
Type: text/x-patch
Size: 3450 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20111017/426dacfe/attachment.bin>

More information about the Gcc-patches mailing list