7.2
P133-L20: "in this section"
P133-L46: "callback functions"
P134-L24-27: incorrect C++ binding (duplicates such as "MPI::Query_function
MPI::Query_function")
P134-L32: "extra_state argument"
P134-L46: "cancellation of the request"
P135-L42: "(see definitions above)" may have to be changed into a reference
to Chapter 2 if Discussion
on P133 is true
7.2.1
P136-L38: "user-defined reduce"
P137-L32: I may be wrong, but it seems to me that the declaration of ARGS
is not in the scope of function
reduce_thread
P137-L41: "MPI_INT, lchild, "
P137-L42: "MPI_INT, rchild, "
P137-L45: "args->comm,"
P137-L47: "MPI_Gr_mark_complete(&(args->request));"
7.4
P140-L14: "passed to MPI_COMM_SET_NAME"
P140-L33: "setting names of less than"
P140-L41: "The name may be set"
P140-L48: I would prefer "points to storage"
P141-L10: "names of "MPI_COMM_WORLD", "MPI_COMM_SELF", and
"MPI_COMM_PARENT""
P141-L35: I would prefer "increase the storage requirement"
7.5
P142-L39: "errorclass on all of"
P142-L40: "new errorclass in a deterministic"
P144-L33: "has not been changed"
MPI_CALL_ERROR_HANDLER allows to invoke the error handler assigned to a
communicator.
I think we would need a similar function for error handler assigned to a
file handle.
Therefore, I would like to introduce (here or in the I/O chapter - section
10.8) the new routine
MPI_FILE_CALL_ERROR_HANDLER(fh, errorcode).
I know this has not been voted in; however, I see this as a minor amendment
to section 7.5.
7.5.1
P145-L9: "which allow users to specify"
P145-L35-36: the MPI macro should produce a continuation line
P145-L40: "For the given datatype,"
P145-L42: "returned can be used to provide"
P145-L44: I would prefer "The combiner specifies the MPI datatype
constructor call"
P146-L13: "combiner is MPI_FUNDAMENTAL if datatype is a fundamental
datatype.
P146-L26: line too long
P147-L5: "ARRAY_ADDRESSES(*)" (one extra "R" to delete)
P147-L19: "returned in array_datatypes"
P147-L23: "returned in array_datatypes"
P147-L31-32: "returns all addresses in an argument"
P147-L39: To me "array_addresses" is not an input argument. Therefore, I do
not understand
the first sentence of the Rationale.
P147-L47: "the following calls were made"
P148-L3: "MPI_ADDRESS_KIND"
P148-L6: line too long
P148-L13: "type" is not of type "int", but of type "MPI_Datatype"
P148-L14: "MPI_Aint a[LARGE]" (extra "\" character and a[] must be
lowercase)
P148-L17: "LARGE" (3 occurrences) must be uppercase
P148-L18: line too long
P149-L4: "array_of_blocklengths"
P149-L11: "array_of_blocklengths"
7.6.2
P151-L17: I would prefer "We call this thread the main thread", since any
reference to it later
in the text is as "main thread"
P151-L18-19: "have no pending communications or I/O operations"
P151-L34: "on any communication or I/O event"
P151-L43: "on a communicator or a file handle is done"
P151-L45: "the same communicator or the same file handle, it is up"
P152-L15: "points where the thread executing"
P152-L16: "no need for the MPI library to be"
P152-L21: "threads). A good programming"
P153-L21: "provided the highest supported level"
7.7
P156-L15-16: I would remove the sentence: "This capability will ...
layering I/O on top of MPI.",
since caching on windows does not apply to this case,
and since I/O should not
always be presented as being layered on top of MPI
(I/O is part of MPI-2).
P158-L20: "This function replaces MPI_ATTR_PUT" (2 corrections)
In MPI 1.1, there is a routine called MPI_ATTR_DELETE which deletes an
attribute cached on
a communicator. I think we should add two routines:
MPI_WIN_DELETE_ATTR(win, win_keyval)
and
MPI_TYPE_DELETE_ATTR(type, type_keyval)
to provide the same capability of deleting attributes cached on windows or
datatypes.
Jean-Pierre