GCC 4.7.0 Status Report (2011-10-11)

[Janne Blomqvist]

On Sat, Oct 15, 2011 at 00:12, Tobias Burnus <burnus@net-b.de> wrote:
> Well, I do not worry about INQUIRE - I really do not think that programs use
> it in a loop. Thus, I am happy with either _commit, or an internal file-size
> read, or the current stat without _commit.
>
> In any case, we should remove the _commit from internal/implict buffer
> flushes. Still, for explicit FLUSH statements (or subroutine calls), I think
> gfortran should make sure that the data ends up such that other programs can
> read the file with the current value.
>
> Users should know that FLUSH is relatively expensive - thus, FLUSH should
> only be sparsely used.

Well, within reason. I don't think making FLUSH orders of magnitude
slower and provide very different robustness guarantees on one
platform is conductive to creating portable applications.  There's
also the issue of how to handle unbuffered files; should we _commit()
after every write then, or?

While the standard of course leaves a lot up to the implementation wrt
IO, I think the intention is pretty clear that it's supposed to be the
equivalent of C stdio fflush() and other similar flush mechanisms in
other languages. There's a reason why fsync()/_commit() is kept as a
separate concept.

If it so happens that writing out data to the OS doesn't immediately
update the file metadata on windows, then I suppose that's they way
stuff works on that platform, and programmers are supposed to handle
it themselves in some way just like they have to do for
C/C++/python/whatnot.

> Would be my patch without the inquire.c change be an
> option for you?

I was thinking something along the lines of the attached patch, which
changes gfortran to use the libgfortran info for the file size when
doing a size inquiry on an open file. Also, in order to preserve
existing behavior at least on POSIX platforms, the buffer is flushed;
while this makes it slower (though still being far lighter weight than
fsync/_commit), like you say, I don't think it's a performance
critical thing.


-- 
Janne Blomqvist
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wincommit.diff
Type: text/x-patch
Size: 1345 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20111015/5957ebca/attachment.bin>