Re: new proposal for spawning processes

Rolf Rabenseifner (Rabenseifner@RUS.Uni-Stuttgart.DE)
Wed, 8 May 1996 10:50:42 +0100 (DST)

My comments and additional proposals

1) > The key idea (separating spawn and attach) was proposed by Eric Salo,
> and the proposal has since been revised and polished after substantial
> commentary from Raja, Al, Greg, Nick, Tony, and myself.

I believe that "separating spawn and attach" is a good idea.
It looks better than the old proposal.
But for the case, that someone detects a real problem in the
new proposal, I think for the first official vote in June
we should have the text of the old proposal although
in the document to stay in the time schedule.


2) The name MPI_CHILD_DETACH could be misunderstood because
it is normally used for functions that change the state from
"attached" to "not attached".

After MPI_SPAWN the state is "not attached".
MPI_CHILD_ATTACH changes the state from "not attached" to "attached".

I would propose the name MPI_CHILD_INDEPENDENT instead of DETACH.


3) > 2. a proposal to replace the info string with an info handle

I think Al Geists proposal, to define the "info-handle-routines"
in a general way like "string-handle-routines"
is good.
Then we can decide independently if we want to use them
for
- info -- or --
- info & command-line

Additionally I propose to automatically free the handle by
the "consuming" routines MPI_SPAWN, MPI_ISPAWN, MPI_PORT_OPEN,
MPI_ACCEPT, MPI_IACCEPT and MPI_CONNECT,
but not by MPI_GET_SPAWNABLE_SIZE.
I think the idea to automaticly free the handle at the next usage
is the key to get an easily usable interface.

My idea of automatic freeing is the following:

handle = MPI_STRING_NULL; /* handle of an empty string */
MPI_String_add ( &handle, string); /* handle is changed */
MPI_Spawn (... &handle, ....); /* handle is freed,
i.e. handle == MPI_STRING_NULL */

Additional functions -- normally not necessary:

MPI_String_dup (in_handle, &out_handle); /* duplication */
MPI_String_get (in_handle, index, max_length, &out_string)
MPI_String_Num (in_handle, out_num);
MPI_String_free (&in_handle);

Because with this interface the %%-algorithm is not necessary
and because normal applications have some effort to concatenate
multi-term info arguments, one can say that this interface is not
more complicated than the current string interface.

I propose, not to have a routine like MPI_String_create because
it would only complicate loops that compose the info argument.

4) Do we need dynamic changing of the services associated with
a port?

If we decide to have the sring handles then I propose to have
the services fixed with MPI_PORT_OPEN with an argument like

IN/OUT services services associated with this port
(string handle)
The string handle "services" will be automatically freed.

Then we can omit MPI_PORT_ADD_SERVICE and MPI_PORT_DELETE_SERVICE.

5) >> Also, this points towards merging spawn with client/server, which
>> would be ideal. After all child_attach is pretty similar functionally
>> to accept/connect, except that the magic info is passed down to the
>> children invisibly.
>
> Exactly. We've not yet really explored how to merge this new model with the
> client/server stuff (at least, I haven't) but ideally they should be very
> similar.

I do not agree. Reasons:

a) If we want to use for client/server and interface like

Clients Servers

MPI_Init MPI_Attach

then the "connection" must be established by the clients
before they call MPI_Init. (In the case of MPI_SPAWN this
"connection" is established by MPI_SPAWN. Here "connection"
means that one side has opened a port and the other side
has got the name of this port.)

I think it is not good to have real stuff at the client
before they call MPI_Init.

b) If we use in MPI_SPAWN a method without a backward
communication channel then typically MPI_SPAWN opens a
port and sends the port name along with the spawning
to the spawned process.
The first connection is then done from parent to child.

Therefore the following table shows the bigest difference
between SPAWN/ATTACH and Client/Server:

SPAWN+ATTACH / MPI_init | Client/Server
|
Role MPI_INIT first conn. | Role MPI_INIT first conn.
----------------------------- | -----------------------------
Parent long ago connector | Server long ago acceptor
Child new acceptor | Client probably connector
| new

I.e. the role of connector and acceptor is reversed !

c) There is no reason that the client makes a new MPI_INIT.
The client can be also a long running MPI application that
sometimes connect to some services.

This are problems if someone wants to bring the proposals
of SPAWN/ATTACH/MPI_INIT and PORT_OPEN/CONNECT/ACCEPT together.

6) Typos:
- NONMPI instead of NOTMPI in the new draft
- IN comm ... (handle) instead of (string) in ACCEPT, IACCEPT
and CONNECT

Rolf Rabenseifner (Computer Center )
Rechenzentrum Universitaet Stuttgart (University of Stuttgart)
Allmandring 30 Phone: ++49 711 6855530
D-70550 Stuttgart 80 FAX: ++49 711 6787626
Germany rabenseifner@rus.uni-stuttgart.de