12.10.4. Releasing Connections

Up: Other Functionality Next: Another Way to Establish MPI Communication Previous: MPI_APPNUM

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.

The following additional rules apply to MPI routines in other chapters:

Advice to implementors.

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.)

INOUT commcommunicator (handle)
C binding
int MPI_Comm_disconnect(MPI_Comm *comm)
Fortran 2008 binding
MPI_Comm_disconnect(comm, ierror)

Fortran binding


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.)


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.)

Up: Other Functionality Next: Another Way to Establish MPI Communication Previous: MPI_APPNUM

Return to MPI-4.1 Standard Index
Return to MPI Forum Home Page

(Unofficial) MPI-4.1 of November 2, 2023
HTML Generated on November 19, 2023