For PVM to interconnect any two groups of processes and allow them to communicate, at least one process in each group must be enrolled into PVM. Processes can become enrolled into PVM by being started by PVM (i.e., implicitly) or by calling a PVM library function (i.e., explicitly). An implicitly started applications may also wish to remain independent, for example, when PVM is used only as a start-up facility. Thus, the system must make sure that even if PVM fails pathologically, it must not be able to interfere with the application's life cycle in any way.
The scope of any communications will depend upon the completeness of membership, that is, fully connected to both systems or partially connected. If full connectivity is not possible, intercommunicator operations could use point-to-point only communications between subsets of nodes. Alternatively, by using extra calls, such operations could use the connected nodes as relays to complete connections.
Another factor in membership is its duration. MPI applications may interact with each other only in a server-client behavior pattern, as in the case of computational steering and visualization, and may not wish to be part of the PVM system continuously. Hence the PVMPI membership is required to be dynamic, as with the current PVM group services, although many PVMPI operations may be required to be blocking and collective to aid correctness, as with current MPI practice.