MPI_PARENT is defined to return MPI_COMM_NULL if the calling process has no
parent; it returns an intercommunicator with local group being the group of
MPI_COMM_WORLD and remote group being the group that called spawn (or detach).
I think a more rationale definition is that MPI_COMM_PARENT always returns an
intercommunicator; the local group is always the group of MPI_COMM_WORLD; the
remote group is empty if the caller had no parent, and is the group of
processes that called spawn (detach), otherwise. Thus, MPI_COMM_WORLD is
always the local part of MPI_COMM_PARENT, and the remote part always include
the parent group (that may be empty).
Incidentally, if we go this way, then MPI_COMM_PARENT can be a predefined
constant, like MPI_COMM_WORLD, rather than a function call. This will reduce
the asymetry between the two
The new proposed defintion for spawning seems to indicate that the spawned
process must start executing before the attach call by the spawner. E.g., the
spawner may send a kill signal to the spawned process, before the attasch, and
expect the signla to be delivered. Or, it might try to communicate with the
spawned processe outside MPI (via of socket, for example), and decide
afterwrds whether to attach or detach.
I would prefer a design that allows the new process to start executing only
when the sapwner executes the attach or detach call. Thuis would allow, for
example, the sapwn call to be merely a call to the resource manager to reserve
a slot for the newly spawned process, and the actual spawning to be done when
the attach/detach call occurs, and more infromation is avaialbe on the new
communication domains to be created. By the way, this would suggest that a
nonblocking attach/detach call would be useful.
This said, I stll prefer better the old proposal. I can certainly imagine
systems where communication hardware is asymetric, and where the right place
to spawn processes will depend on their communication requirements: E.g., on
a cluster of SMPs, I would spawn a detached group of processes that
communicate between them on one SMP node, if possible; on a heterogenous
environment I would spawn them on one system, if possible. With the new
proposal, I don't have any hint on the expected communication pattern when the
processes are spawned.
IBM T.J. Watson Research Center
P.O. Box 218, Yorktown Heights, NY 10598