I like this. In fact Suresh's spawn_fn() is basically the same as
MPI_GROUP_START_INDEPENDENT (they take different args but basically do
the same thing). I could see coalescing these in such a way that
MPI_GROUP_START_INDEPENDENT becomes the default value for spawn_fn().
The big question still unanswered, if you take this road, is
rendezvous (how the children learn about the parent, and how the MPI
protocol gets started). If you don't assume that command-line args or
environment variables can always be passed, then this is a tough
problem. Of course if you do, then it's easy, you just pass the
startup info in some magic args.
I earlier proposed a similar generic callback scheme for rendezvous
where the runtime environment could provide functions to send a short
message from parent to children and vice versa (in case a handshake is
necessary to start the MPI protocol; maybe you can always get by with
a one-way transmission like command-line args give you).
I guess systems which lack cmd-line args are assumed to exist by the
committee, otherwise START_ATTACH could be eliminated, since it's a
simple variant on
REGISTER(magic string)
START_INDEPENDENT(with cmd line arg for magic string)
PROCESS_ACCEPT(magic string's handle)
(assuming MPI_INIT is made to look for the cmd line arg with the magic
string and call PROCESS_CONTACT).
Note that in my application, the app itself is the runtime system. It
has ways of starting and managing processes (above the standard Unix
or PC exec/rcmd stuff). It's unlikely that anyone's standard MPI
SPAWN implementation will call my process starting functions. I was
planning to use client/server for this, but a flexible SPAWN is really
ideal for me.
-- 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