12.10.4. Releasing Connections

Before a client and a server connect, they are independent MPI applications. An error in one does not affect the other. After establishing a connection with MPI_COMM_CONNECT and MPI_COMM_ACCEPT, an error in one may affect the other. It is desirable for a client and a server to be able to disconnect, so that an error in one will not affect the other. Similarly, it might be desirable for a parent and child to disconnect, so that errors in the child do not affect the parent, or vice-versa.

• Two processes are connected if there is a communication path (direct or indirect) between them. More precisely:
  1. Two processes are connected if
  1. they both belong to the same communicator (inter- or intra-, including MPI_COMM_WORLD) or
  2. they have previously belonged to a communicator that was freed with MPI_COMM_FREE instead of MPI_COMM_DISCONNECT or
  3. they both belong to the group of the same window or file handle.
  
  2. If A is connected to B and B to C, then A is connected to C.
• Two processes are disconnected (also independent) if they are not connected.
• By the above definitions, connectivity is a transitive property, and divides the universe of MPI processes into disconnected (independent) sets (equivalence classes) of processes.
• Processes that are connected, but do not share the same MPI_COMM_WORLD, may become disconnected (independent) if the communication path between them is broken by using MPI_COMM_DISCONNECT.

• MPI_FINALIZE is collective over a set of connected processes.
• MPI_ABORT does not abort independent processes. It may abort all processes in the caller's MPI_COMM_WORLD (ignoring its comm argument). Additionally, it may abort connected processes as well, though it makes a ``best attempt'' to abort only the processes in comm.
• If a process terminates without calling MPI_FINALIZE, independent processes are not affected but the effect on connected processes is not defined.

In practice, it may be difficult to distinguish between an MPI process failure and an erroneous program that terminates without calling an MPI finalization function: an implementation that defines semantics for process failure management may have to exhibit the behavior defined for MPI process failures with such erroneous programs. A high quality implementation should exhibit a different behavior for erroneous programs and MPI process failures. ( End of advice to implementors.)

This function waits for all decoupled MPI activities on comm to complete internally, deallocates the communicator object, and sets the handle to MPI_COMM_NULL. It is a collective operation.

It may not be called with the communicator MPI_COMM_WORLD or MPI_COMM_SELF.

MPI_COMM_DISCONNECT may be called only if all communication is complete and matched, so that buffered data can be delivered to its destination. This requirement is the same as for MPI_FINALIZE. This means that before calling MPI_COMM_DISCONNECT, all request handles associated with comm must be freed in the case of nonblocking operations, and must be inactive or freed in the case of persistent operations (i.e., by calling one of the procedures MPI_{TEST|WAIT}{|ANY|SOME|ALL} or MPI_REQUEST_FREE).

MPI_COMM_DISCONNECT has the same effect as MPI_COMM_FREE, except that it waits for decoupled MPI activities on comm to finish internally, disallows any further use of derived inactive persistent requests, and enables the guarantee about the behavior of disconnected processes. The decoupled MPI activities also include any communication that is needed to complete a nonblocking or persistent operation on comm that was freed with MPI_REQUEST_FREE. After calling MPI_COMM_DISCONNECT, freeing or starting an inactive persistent request handle for a communication operation on comm is erroneous.

Advice to users.

To disconnect two processes you may need to call MPI_COMM_DISCONNECT, MPI_WIN_FREE, and MPI_FILE_CLOSE to remove all communication paths between the two processes. Note that it may be necessary to disconnect several communicators (or to free several windows or files) before two processes are completely independent. ( End of advice to users.)

Rationale.

It would be nice to be able to use MPI_COMM_FREE instead, but that procedure explicitly does not wait for decoupled MPI activities to complete, and it does not disallow freeing or starting of related inactive (but not yet freed) persistent request handles. ( End of rationale.)