Re: MPI_SPAWN

William C. Saphir (wcs@nas.nasa.gov)
Fri, 20 Oct 1995 14:33:19 -0700

On Oct 20, 3:03pm, Suresh Damodaran-Kamal wrote:
> Subject: MPI_SPAWN
>
> The new dynamic spawn document does away with interfaces to
> resource managers altogether. However, the document
> says that "complex interaction of an MPI application with its runtime
> environment should be done through an environment specific API."
>
> The following is a sample scenario:
>
> Assume that the runtime environment is PVM.
> Then, it appears to me that somehow MPI_SPAWN() must result in a call to
> pvm_spawn(). Otherwise, how will the PVM runtime know about
> the status of resources and processes running under it?
>
> Does this mean there will be different versions of MPI_SPAWN() for
> different runtimes (operating systems + PVM + ...)?
>-- End of excerpt from Suresh Damodaran-Kamal

Absolutely. An MPI implementation will have to work with the
runtime system at a level below what the user sees.
This isn't new in the current proposal, though.

I agree it is a barrier to portability. One solution
to the portability problem is to specify the interface
explicitly.
I personally suspect this is impossible to do in a way that
works well with *all* (or even most) runtime environments.
If it's possible, then what we need is a specific proposal
to think about. I haven't written such a proposal because
I don't see how to do it, but someone with a clear vision
could write one.

The solution I'm hoping for is that a public domain implementation
(MPICH or LAM or even the PVM folks) will come up with a nice interface that
works in a bunch of cases but may not be completely flexible.
Vendors can implement their own system and *also* provide
an interface compatible with this pseudo-standard interface.
Folks needing a portable interface (debuggers, for instance)
could write for this portable one. Of course it wouldn't
provide full flexibility and wouldn't work everywhere, but
I think it would help a lot.

I see this also as a solution for interoperability between different
MPI implementations. For instance, implementations could
standardize on MPICH/P{3,4} socket protocol for heterogeneous
communication. However, the MPI Forum would never consider
requiring the protocol for all MPI implementations.

So I see this as primarily an implementors issue.

Bill