- Page 47, bottom, says "MPI does not require the existence of an
underlying "virtual machine" model, ..." and later has advice to
implementors that says "A virtual machine abstraction is appropriate
in most environments and should be part of a "high-quality"
implementation. In other cases, providing the virtual machine
abstraction may add too much baggage (e.g., daemon processes) or
Bill notes that the advice to implementors is loaded and doesn't belong.
My recollection is that this language was an intentional
clarification that was important back in the days of
MPI_SIGNAL and MPI_PROCESS_MONITOR. At this point, I don't have
a problem taking out the a.t.i. and will do so unless there
- Page 50, top. In advice to implementors, we discuss "natural" rules
for finding executables, ending with "A high-quality implementation
will give the user some control over how executables are
found and working directories are determined." Bill suggests
adding some text about documentation, for which I would suggest:
"Implementations should document how executables are found
and working directories are determined." Seems pretty innocuous.
- The description of MPI_COMM_PARENT is not right. (page 52).
I suggest the following text:
"MPI provides a predefined intercommunicator MPI_COMM_PARENT. The
local group of MPI_COMM_PARENT is identical (MPI_GROUP_COMPARE returns
MPI_IDENT) to the group of MPI_COMM_WORLD. If a process was spawned
with MPI_SPAWN or MPI_SPAWN_MULTIPLE, the remote group is identical to
the group of MPI_COMM_WORLD in the parent. Otherwise, the remote group
of MPI_COMM_PARENT has size zero (see MPI_COMM_REMOTE_SIZE)."
This brings up another issue which is that we say
"The intercommunicator returned by MPI_SPAWN contains the parent
processes in the local group and the child processes in the remote
group." We should probably clarify further that:
"The ordering of processes in the local and remote groups of this
intercommunicator is the same as the ordering in the groups of
MPI_COMM_WORLD, for parents and children respectively. "