First of all, we need a better definition of the end of file, and of the append
mode.
As long as we maintain shared offsets, and that we keep
the possibly called MPI_XXX_ORDERED functions, do we really need an append
mode, which does not guarantee the Unix semantics?
For the end of file, I think all tasks of an MPI application should have the
same value for it. This is the byte located, in the canonical representation of
the file considered as a byte stream, right after the last byte written
(default to zero at file creation) to the file. This is different from the
value returned by MPI_GET_SIZE on that file. If the file is expanded through
MPI_RESIZE, the end of file does not change, only the preallocation size of the
file changes and the hole so created has undefined values. If the file is
instead truncated, the end of file changes accordingly.
Now, what needs to be clearly defined is the scope of the preallocation size of
a file ? Is it permanent ? Does it go away when the file is closed ? What about
other processes accessing the file when the process which preallocated the
space closes the file ?
We should try to resolve all discussion items which are in the document:
page 239 (2), page 241 (1), page 242 (1), page 244 (2), page 245 (1),
page 247 (1 - cf below), page 253 (2), page 254 (1), page 267 (1), page 272
(1), page 275 (1).
We need to decide if we go with a counter-proposal for views which contain an
extra parameter, specifying the maximum number of replications of the filetype,
before the next view should/must/may be defined.
We are still waiting for a proposal that would allow the support for non-local
I/O servcies (Richard, any suggestion ?).
The interoperability section need to be reviewed and completed.
The exact semantics of close, iclose, delete must be specified, with regard to
outstanding asynchronous requests.
How do we get the atomicity associated with an open file ? Not very clear to me
how MPI_ATOMICITY can do it. I think we need a function to get access to the
file name associated with a file, and another one to get access to the mode of
a file (especially since the mode stipulates now what data format is present in
the file).
When querying the view of a file, the user must allocate space for info_taken ?
How can she know how much space is required to hold all the hints currently
active for the open file ?
Here are a few typos and suggestions:
page 241 (line 26): A small subsection, entitled "Notation", or just a
paragraph, should define what the notation [SAME] stands for.
page 245 (lines 22-23): "the beginning of the data accessible in the file
through that view is set to disp" instead of "the beginning of the file is set
to disp".
page 247 (lines 39-42): should be a discussion item.
page 263 (line 28): the title should rather be: "Query Individual File Pointer
Position".
page 263 (lines 34-35): "individual file offset" instead of "file offset".
page 263 (lines 46-47): filetype should not be in boldface.
page 271 (line 32): the title should rather be: "Query Shared File Pointer
Position".
page 271 (lines 38-39): "shared file offset" instead of "file offset".
page 272 (line 1): first word should be "MPI_GET_POSITION_SHARED".
page 272 (lines 2-3): filetype should not be in boldface.
page 274 (line 45): "argument" instead of "arguement".
Jean-Pierre