Steve
205/23-25: The two phrases, "beginning of a file" and "relative to the
default view" are confusing me about what displacement is.
206/fig 10.1: the words in the figures really need a bigger font.
206/fig 10.2: the words in the figures really need a bigger font.
Also, would it be better to use processes 0-2 instead of 1-3?
207: I think having words saying that all errors from MPI_OPEN are
raised on the comm would be a good idea. I am thinking about errors
that might happen after the fh is formed that some implemenation might
choose to raise on fh instead of comm.
208/15: "in the addition!" -> in the addition.
I don't like having the emphasis here (somewhat personal choice).
208/22: I think we should either say what are POSIX semantics or give
a reference. A reference is probably an cleaner solution.
208/22-23: "Exactly one of MPI_RDONLY, MPI_RDWR, OR MPI_WRONLY, must
be specified." I just want to check that you must give one of these
and what was really intended wasn't that you can't give 2 of
them. (i.e., the current text excludes giving none.)
208/27-9: I assume the restriction that no concurrently opened for
MPI_UNIQUE_OPEN includes another program/shell. If so it might be
nice to clearly warn the user since external events can cause
unexpected behavior.
210/11: MPI_FILE_HANDLE_X needs the name fixed.
210/28: "the file handle fh" -> the file handle fh,
210/36: MPI_PREALLOCATE -> MPI_FILE_PREALLOCATE
210/36: I think it would be good to define what happens if the
MPI_FILE_SET_SIZE fails because the impl. cannot deal with it.
212/14&5: "communicator group" -> group. I think this is the way it
is referred to everywhere else.
212/32: says example "portably decoding" but the code has a "MAXBITS =
30". I think it isn't truely portable.
213/22-3: "regarding file access patterns and file system specifics to
direct optimization" ->
including file access patterns, file system specifics, and
direct optimization
213/27: time -> call
214/45+: all the key values (e.g., read_once, etc) seem to have use
the key macro so they show up in info key appendix. They aren't
really keys but constants that the key value can use. I think the
macro needs changing (or maybe a new one added).
216/23: fh is listed as IN for MPI_FILE_SET_VIEW. What I am wondering
is if it should be INOUT. Clearly the values pointed to in fh are
modified. Unlike some of the other cases recently debated, user
visible values are involved. If this idea is accepted it effects lots
of rouintes in this chapter. It may alos effect other routines in
other chapters so we need to make a global decision.
217/fig 10.3: fonts too small
218/35: "filetype respectively" -> filetype, respectively
220/20: "The standard" -> MPI
220/34+: It seems to say _ORDERED is just like non-ordered but
collective. This is true for _ALL but _ORDERED also imposes a
specific sequential order.
221/34: I think the cancelled field in status may also have to be
filled in. It seems that one should be able to test this since I
assume I/O operations can be cancelled. If true effects later text too.
221/38,222/37,225/13,226/2: The language neutral part of the function
definition is missing in all 4 of these places.
223/32,224/16: Can extract info with new non-distructive status
inquiry in MPI-2 in addition to test & wait.
224/46: Status -> status
227/29: Is the offset in etypes? I think it needs to be to make the
following GET routine make sense. If so, it should say this.