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
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
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
I do not agree. Reasons:
a) If we want to use for client/server and interface like
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
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.
- NONMPI instead of NOTMPI in the new draft
- IN comm ... (handle) instead of (string) in ACCEPT, IACCEPT
Rolf Rabenseifner (Computer Center )
Rechenzentrum Universitaet Stuttgart (University of Stuttgart)
Allmandring 30 Phone: ++49 711 6855530
D-70550 Stuttgart 80 FAX: ++49 711 6787626