Skip to content

Commit

Permalink
Clarify three roles of consumers the PMIx interface
Browse files Browse the repository at this point in the history
 * Clarify the three roles of consumers of the PMIx interface (clients / servers / tools)

Signed-off-by: Joshua Hursey <[email protected]>
  • Loading branch information
jjhursey committed Feb 4, 2021
1 parent 8446a24 commit 4e06028
Showing 1 changed file with 31 additions and 0 deletions.
31 changes: 31 additions & 0 deletions Chap_Introduction.tex
Original file line number Diff line number Diff line change
Expand Up @@ -200,3 +200,34 @@ \subsection{Attributes in PMIx}
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{PMIx Roles}

The role of a \ac{PMIx} process in the \ac{PMIx} universe is grouped into one of three categories based on how it operates in the \ac{PMIx} environment namely as a \emph{client}, \emph{server}, or \emph{tool}.
As a result, there are three corresponding sets of initialization and finalization functions.
If a process initializes as either a \emph{server} or a \emph{tool} that process may also access all of the \emph{client} \acp{API}.

A process operating as a \refterm{client} is started (directly or indirectly, for example, by an intermediate script) by the \ac{RM} and is connected to the \ac{PMIx} server instance within that \ac{RM} when the client calls the client \ac{PMIx} initialization routine.
A process operating as a \declareterm{server} is responsible for starting client processes and coordinating with other server and tool processes in the same \ac{PMIx} universe.
Often processes operating as a \emph{server} are part of the \acf{RM} infrastructure.
A process operating as a \declareterm{tool} will connect to a \ac{PMIx} \emph{server} to interact with the processes in the \ac{PMIx} universe.
An example of a \emph{tool} process is a parallel debugger that will connect to the server to assist with attaching to a set of client processes.

\ac{PMIx} serves as a conduit between processes acting in these three different roles.
As such, an \ac{API} is often described by how it interacts with processes operating in other roles in the \ac{PMIx} universe.

\adviceimplstart
A \ac{PMIx} implementation may support all or a subset of the \ac{API} role groupings defined in the standard.
A common nomenclature is defined here to aid in identifying levels of conformance of an implementation.

A \ac{PMIx} implementation that supports all three sets of the \ac{API} role groupings is said to be \emph{fully \ac{PMIx} standard compliant}.
These \emph{fully \ac{PMIx} standard compliant} implementations have the advantage of being able to support a broad set of \ac{PMIx} consumers in the different roles.

Alternatively, a \ac{PMIx} implementation may choose to support fewer than all three sets of the \ac{API} role groupings.
A \ac{PMIx} implementation that supports only the \emph{client} \acp{API} is said to be \emph{client-only \ac{PMIx} standard compliant}.
Similarly, a \ac{PMIx} implementation that only supports the \emph{client} and \emph{tool} \acp{API} is said to be \emph{client-and-tool-only \ac{PMIx} standard compliant}.
Finally, a \ac{PMIx} implementation that only supports the \emph{client} and \emph{server} \acp{API} is said to be \emph{client-and-server-only \ac{PMIx} standard compliant}.

Note that it would not make sense for an implementation to exclude the \emph{client} interfaces from their implementation since they are also used by the \emph{server} and \emph{tool} roles.
\adviceimplend

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

0 comments on commit 4e06028

Please sign in to comment.