One note on the scalability issue. In MPI-1, even on MPPs, a user
starts the scalable application from a single window/command-line.
Implementations either directly, or with the help of a single resource
manager (any distributed RMs?) start up the N processes in the best way
they can. So I tend to see a spawn() from a single process along the
same line as MPI-1 startup, except it's part of the API and it's
standardized. In the current proposal spawn() takes a root argument,
with the understanding that all that is needed to do the spawn is only
guaranteed to the valid at that root (not just "info", but access to the
binaries as well, etc.). Vendors may make different assumptions, but
the standard only guarantees valid spawn "prerequisites" at that root.
In any event, if implementors want to be able to spawn collectively,
the comm & root arguments can be added to spawn without changing the
value of the new proposal. The main issue in my mind is that breaking
the spawn part from the comm-creation part makes us move from the
current proposal's 12 functions (spawn/indep/non_mpi * block/non-block *
single/multiple), to the new proposal's 4 functions to handle equivalent
functionality (spawn/ispawn, child_attach/detach) [plus the help of
the under-utilized MPI-1 group functions :-) ].
If there is a correct procedural mechanism to get this proposal included
in the text (after a vigorous email-debate), I'd be in favour of that.
This wouldn't necessarily impact the MPI-2 schedule. An official vote
at the next meeting would select between the two proposals, then we
officially vote on the chapter. Would that be an acceptable approach?
--Raja