First:
I thought for a long time about how to eliminate some of these
functions, and (since I couldn't) I congratulate you folks on a good
job -- I think they're all useful in one way or another. There's a
simple matrix for the "interesting" starting functions as seen from
the server (or master)'s side:
Connect Don't Connect
.======================= =============================
Start Child| MPI_SPAWN or MPI_GROUP_START_INDEPENDENT
| MPI_GROUP_START_ATTACH
|
Don't Start| MPI_PROCESS_ACCEPT xxx
The client only has two choices:
Know about server: MPI_PROCESS_CONTACT
Don't know: MPI_INIT
I agree MPI_SPAWN is politically necessary, even though it's trivial
given GROUP_INIT and START_ATTACH. And I guess we have to keep
GROUP_START_INDEPENDENT, which as far as I can tell has nothing to
do with MPI except that the MPI2 implementation will have to have
some way of starting processes remotely, so since "we have to write
it anyway, might as well give it to the users."
If you could always assume that cmd-line args are available, I could
see how you could eliminate two of these functions
(MPI_PROCESS_CONTACT and MPI_GROUP_START_ATTACH), but I think you're
right to keep portability and not assume that.
I think ACCEPT/CONTACT are really the "fundamental primitives" here,
but I can't see any way to exploit that to simplify the other
interfaces, at least in a portable way.
Second:
If you want to start multiple binaries with different args in a
single group, are you supposed to call group_init multiple times,
and then use MPI_GROUP_UNION to suck up all the groups into one, and
then call START_* on *that* group? If so, you might want to add a
bit to the spec on p. 8, lines 35 & 41, saying "...group returned by
MPI_GROUP_INIT, or a combination of such groups."
What error should be returned if you call MPI_GROUP_UNION on a group
returned by MPI_GROUP_INIT and your MPI_COMM_WORLD's group?
Third:
What about (for simplicity, given that I'm going to read the args
for MPI_GROUP_INIT from a file) just calling MPI_GROUP_INIT from one
process, and having an extra "root" arg to MPI_GROUP_START_ATTACH,
(or just pass some NULL group) to say where the group is valid?
After all, it has to be the same everywhere, right?
Fourth:
Conceptually, the MPI_GROUP that's passed from MPI_GROUP_INIT to
MPI_GROUP_START_* is not a "normal" group. Its contents are
executable names, argument vectors, and so on, not real processes.
Is it really right for it to be a group? After all you can't pass a
"normal" (existing-processes) group into MPI_GROUP_START_*. And
what if some day you want to provide group accessors? You'll need
two sets for the two kinds of things that can be in a group. I
suggest a separate datatype, MPI_NEWGROUP or something.
Fifth:
I presume the reason for MPI_PROCESS_REGISTER to exist (rather
than passing the string directly to ACCEPT) is that you'll want to run
ACCEPT frequently, but only REGISTER once? Perhaps a note to that
effect could be added to the chapter.
Last:
Any idea when preliminary versions of this stuff will begin to show
up, say in MPICH or LAM? I am willing to help (a little) if need
be, since this is central to my application, and thus my job. :-)
Thanks again for a great job; I'm counting on you folks!
-- Gary Oberbrunner garyo@avs.com Advanced Visual Systems, Inc. http://www.avs.com/~garyo 300 Fifth Avenue (617)890-8192 x2133 TEL Waltham, MA 02154 (617)890-2887 FAX