Yes, I know that we're supposed to be "done" with the dynamic chapter at this
point and that everything has been voted in twice. So let's handle this as an
amendment. (The wonderful thing about amendments is that you can propose
anything you want and get it accepted with only a single vote!) Formally, then,
the proposed amendment is to replace all of section 4.4 with the following
single routine, with the usual promises to provide an appropriately formatted
version in the near future:
------
MPI_SAPHIR_JOIN(IN fd, IN info, IN root, IN comm, OUT intercomm)
'fd' is a file descriptor representing a socket of type SOCK_STREAM (two-way
reliable byte-stream connection), with no pending communication, created by the
user. The file descriptor is closed on return. MPI uses this descriptor to
bootstrap MPI communication between a local communicator and a remote one. Note
that MPI is free to use communication paths other than TCP for MPI messages, we
only need the socket for the initial handshaking.
'info' might contain hints about the best way to boostrap the communication
(e.g., if there are two possible networks or protocols, pick one).
'root' is used to specify which process in 'comm' contains the file descriptor
(and possibly the info arg).
The call is exactly the same for client and server, so it doesn't matter who
did bind+listen+accept and who did connect.
The caveat would be that this is specific to an environment in which such
streams are available (not sure what the appropriate standard is - POSIX?
Berkeley sockets?).
The rationale is that MPI's current facilities are a really just a thinly
veiled renaming of existing mechanisms that is unlikely to provide any
additional functionality and does not provide all the flexibility of the
existing mechanisms. The mapping is:
MPI_PORT_OPEN -> socket + bind()
MPI_PORT_SET_QUEUELEN -> listen()
MPI_ACCEPT -> accept()
MPI_CONNECT -> connect()
MPI_NAME_PUBLISH
MPI_NAME_GET
have no clear mapping and are unlikely to be implemented in most environments.
Other mechanisms are probably better, and should be under user control anyway.
------
Comments? (This should be fun...)
-- Eric Salo Silicon Graphics Inc. "Do you know what the (415)933-2998 2011 N. Shoreline Blvd, 8U-802 last Xon said, just salo@sgi.com Mountain View, CA 94043-1389 before he died?"