>The new, counter-proposal should be held in reserve to be brought
>into the discussion only if we decide we want to radically change
>the current semantics of MPI_Spawn.
My reading is the majority of the dynamic committee is in agreement to
present the new proposal. It is on the table, it has to be discussed.
The new proposal was hashed out by a group that included several
implementors, users, and international members. It is simple,
elegant, complete, and provides all the functionality that we have spent
the last several meetings voting in.
> The "problem" has arisen in the following way:
> ...flags... many functions...
No Rusty, the problem arose when we finally understood the
functionality we wanted SPAWN to provide and we stepped back
to see what the API looked like (and it wasn't a pretty site).
We realized the functionality was possible without the complexity.
>The right way to reduce the number of functions is by voting out the
>functionality, not by messing up the core functionality.
>...Greater functionality requires more functions.
I do not like Rusty's approach of reducing the number of functions
by voting out functionality. I know from PVM experience that users
want the functionality that we have decided on. The new proposal shows
that greater functionality does not require more functions.
Rusty argues for the trusty old MPI_SPAWN that returns an intercomm.
This can be provided as a simple convenience function using the
new proposal's routines.
>Our current MPI_SPAWN does this just exactly right. It is a
>single call, collective, and returns a communicator ready to use. We have
>begun implementing it, and it works fine.
Great, you have done the simplest case Rusty. Let's talk again when
you try to implement the fortran version of MPI_SPAWN_MULTIPLE_INDEPENDENT_MPI
SGI, Convex, LAM, and Intel implementors were deeply involved
in designing the new dynamic proposal. So I feel comfortable
saying I speak for the implementors and users that the
proposal should be given serious consideration.
Al Geist
-----