Re: latest version of dynamic chapter
Rolf Rabenseifner (Rabenseifner@RUS.Uni-Stuttgart.DE)
Tue, 27 Feb 1996 12:11:59 +0100 (MEZ)
Four topics to the draft "dynamic" 23FEB96:
1. An error corrections:
page 7 last line: "first m entries" instead of "n"
2. A comment and a proposal:
page 11 discussion about MPI_UNIVERSE_SIZE:
It was not "not enough" for me, it was inconsistent with
the definition of MPI_SPAWN.
To avoid "getting into the mess of interaction..."
one can propose:
MPI_UNIVERSE_SIZE( in: info, out: size)
with an allowed new error code
Then MPI implementations on systems with a fixed number of
processes can compute the size in a probably simple way
and MPI implementations that allow a more open space of
resources that can be specified in "info", can return
MPI_ERR_SIZE_UNKNOWN (e.g. because there is no way
to determine, if a rsh-call will run correct, before
submitting it really with MPI_SPAWN)
Wouldn't it be better to put all proposals into the draft
and to make a straw vote in Chicago, than to delete all now?
3. A comment to "3.4 Attaching to Independent Processes":
In the actual proposal the functionality of MPI_REGISTER_NAME
is not clear:
"The given_name is 'published' in such a way that the client
can learn it. ...
For the time being, we do not specify a name server interface
and leave unspecified (outside the scope of MPI) the
publication mechanism. ..."
Because a portable MPI program is allowed to use any name service
there can be trubbles if the application uses the same name
servoce as that one used by the MPI implementation, because
both are calling name_service_register(name, ...) with the same
And the example page 22f line 19ff cannot be programmed, because
MPI_COMM_FREE is wrong designed.
This are CONTRAs to the actual proposal
4. I think, if one wants to "do not specify a name server interface",
then my following proposal is better:
MPI_OPEN_PORT(port) (instead of MPI_REGISTER_NAME)
OUT port_name character string supplied by the system
In MPI_ACCEPT ... MPI_ICONNECT
instead of IN given_name
now IN port_name
IN newcomm intercommunicator returned by CONNECT/ACCEPT
IN port_name character string supplied by the system
The chapter 3.4.1 must be simplified accordingly then:
1. With MPI_OPEN_PORT the server process gets the name (address
information, e.g. host:port, but we do not specify this)
of a newly opened port.
This port can be used for several connections.
2. It is not specified by this standard, how the server
application "publishes" this port_name and how the
client can learn it. The application can use each
arbitrary name service for the registration of its
service along with its port_name.
3. ... (same text) .... port_name.
4. ... (same text) ...
5. The communicator is destroyed when both client and server
processes call the collective operation MPI_RELEASE.
6. The server can free the port with MPI_CLOSE_PORT when
it no longer wishes to establish new connections with
MPI_ACCEPT or MPI_IACCEPT.
MPI_CLOSE_PORT must be called only by the root process,
that called MPI_OPEN_PORT.
In the Client-server-example:
MPI_Comm_free must be substituted by MPI_Release
MPI_Close_port con not be called because "while (1)"
does not finish.
If you put all into the draft, we can discuss it in Chicago.
Rolf Rabenseifner (Computer Center )
Rechenzentrum Universitaet Stuttgart (University of Stuttgart)
Allmandring 30 Phone: ++49 711 6855530
D-70550 Stuttgart 80 FAX: ++49 711 6787626