> > - MPI_Comm_parent, managing MPI and non-MPI processes
> >
> > * 3. start non-MPI processes (e.g., a task farm)
>
> I agree with these objectives, but might also add a fourth
> 4. start a non-MPI parallel program.
I believe 3 and 4 are identical.
> > It is necessary to distinguish at this point between MPI_CHILD and
> > MPI_ORPHAN so that MPI_Comm_parent functions correctly (i.e. doesn't
> > block if the parent doesn't wish to communicate with the children.)
> > This precludes the possibility of spawning processes where you don't
> > know whether you will want to communicate with them. That's fine, I
> > think.
I agree with Bill S.
(James Cownie:)
> The argument is that "extra command line flags" will be given to an
> MPI program, even if it is not connecting back to the spawner. I'm
> afraid I don't like this at all. It seems to be inviting
> problems by providing the user with another thing to get wrong.
>
> Surely it's much simpler and more secure to push appropriate things
> into the environment and then pick them up in the child. This way they
> only affect child processes which are looking for them, and will be
> implicitly ignored (like all the rest of the environment) by processes
> which aren't interested.
What user? :-) I believe the main users of MPI will be library
writers who already have some experience with execvp, etc.
Further, it is poor to assume that the child will be launched in
a local Unix environment.
> It would actually be possible to do away this process type argument
> completely, since the additional information needed to locate the
> parent could also be pushed into the environment (always) and then
> picked up by MPI_Comm_parent.
What about environments where interaction with the O/S is slow and/or
undesirable?
Richard Frost
SDSC