Re: new dynamic proposal

Eric Salo (salo@mrjones.engr.sgi.com)
Thu, 9 May 1996 12:28:54 -0700

Rusty, we made a very deliberate effort to include as much of the flavor of the
current chapter as possible when we put together this new proposal. For
example, many of use would really like to see the 'minprocs' argument to
MPI_Spawn() disappear, but the most recent straw vote was to keep it and so we
did, too. Ditto for spawning non-MPI processes, we would have loved to have
forbidden it but we kept it in because that was the state of the current
chapter.

So I would argue that this proposal is not nearly as radical as it might appear
at first. The only real difference is the API, which does of course have some
consequences for implementors. Exactly what those consequences are is something
that we must now determine.

Regarding your specific points, I basically agree with Bill's answers. In our
specific implementation, we would not derive any benefit from making the spawn
operation collective for the parent communicator. Instead, we would most likely
implement the current chapter by performing a spawn on a single process and
then doing a broadcast at the parent's end to set up the intercommunicator. I
would also like to hear from the MPP vendors on this, are there concrete
advantages to making the spawn operation collective?

And, just for the record, I'd like to say that I very much prefer the new
API...

-- 
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?"