It seems to me that we have two fundamentally contradictory goals here. On the
one hand, we don't want to dictate what the execution environment must be. On
the other hand, we want these nice clean definitions about what it "means" to
call MPI_Init() or to "be spawned" or to "have a parent".
In PVM, we have this notion of "being spawned". At startup time, then, a PVM
process gets to find out whether it has, in fact, been spawned. If so, it may
conclude that it is the "master" and may start spawning off slave copies of
itself. I think that this is a very important point to note: the same
executable image works for both master and slave.
In MPI-1, we have a static model only. How, then, do we set up master/slave
applications? We can't just call MPI_Have_I_been_spawned() because MPI-1 has no
notion of this. There are only a few choices:
The first choice is to start all of the processes at once and then just key off
of your rank in MPI_COMM_WORLD to determine whether you are master or slave.
However, this will not work in MPI-2 in the context of dynamic spawning.
The second choice is to use two different executable images, one for the master
and one for the slaves. I claim that fundamentally, this is exactly the model
that MPI programmers will eventually have to start using because it is the only
way that I know of to address these conflicting goals. An MPI-2 program should
not ever need to call MPI_Have_I_been_spawned() because it will already know
this implicitly.
So all that we lose is the ability to compile everything into one nice clean
image. While this would certainly be nice, I don't see any way to make it work
given the lack of restrictions that we are currently mandating in our execution
environments.
Fire away...
-- Eric Salo Silicon Graphics Inc. "Do you know what the (415)933-2998 2011 N. Shoreline Blvd, 7L-802 last Xon said, just salo@sgi.com Mountain View, CA 94043-1389 before he died?"