You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: Chap_API_Struct.tex
+21-23Lines changed: 21 additions & 23 deletions
Original file line number
Diff line number
Diff line change
@@ -46,7 +46,7 @@ \section{Constants}
46
46
\end{constantdesc}
47
47
48
48
\adviceimplstart
49
-
\refconst{PMIX_MAX_NSLEN} should have a minimum value of 63 characters. Namespace arrays in \ac{PMIx} defined structures must reserve
49
+
Namespace arrays in \ac{PMIx} defined structures must reserve
50
50
a space of size \refconst{PMIX_MAX_NSLEN}+1 to allow room for the \code{NULL} terminator
51
51
\adviceimplend
52
52
@@ -57,7 +57,7 @@ \section{Constants}
57
57
\end{constantdesc}
58
58
59
59
\adviceimplstart
60
-
\refconst{PMIX_MAX_KEYLEN} should have a minimum value of 63 characters. Key arrays in \ac{PMIx} defined structures must reserve
60
+
Key arrays in \ac{PMIx} defined structures must reserve
61
61
a space of size \refconst{PMIX_MAX_KEYLEN}+1 to allow room for the \code{NULL} terminator
62
62
\adviceimplend
63
63
@@ -87,10 +87,8 @@ \subsection{PMIx Return Status Constants}
87
87
\adviceimplend
88
88
89
89
\adviceuserstart
90
-
Other than \refconst{PMIX_SUCCESS} (which is required to be zero), the integer value of any \ac{PMIx} error constant is left to the \ac{PMIx} library implementer with the constraint that it be negative and greater magnitude (i.e. of larger absolute value)
91
-
than
92
-
\refconst{PMIX_EXTERNAL_ERR_BASE}.
93
-
Thus, users are advised to always refer to constants by name, and not by a specific implementation's integer value, for portability between implementations and compatibility across library versions.
90
+
Other than \refconst{PMIX_SUCCESS} (which is required to be zero), the integer value of any \ac{PMIx} error constant are negative and of greater magnitude (i.e. of larger absolute value) than\refconst{PMIX_EXTERNAL_ERR_BASE}.
91
+
For compatibility with future versions, users are advised to always refer to constants by name, and not by their integer value which may be specific to an \ac{ABI} version.
94
92
\adviceuserend
95
93
96
94
The presentation of each \ac{API} in this document includes a list of return status constants which are either specific to that \ac{API} or are expected to be returned by the \ac{API} in normal use.
@@ -473,7 +471,7 @@ \subsubsection{Process structure support macros}
473
471
474
472
Provide a static initializer for the \refstruct{pmix_proc_t} fields.
475
473
476
-
\versionMarker{4.2}
474
+
\versionMarker{5.0}
477
475
\cspecificstart
478
476
\begin{codepar}
479
477
PMIX_PROC_STATIC_INIT
@@ -797,7 +795,7 @@ \subsubsection{Process information structure support macros}
797
795
798
796
Provide a static initializer for the \refstruct{pmix_proc_info_t} fields.
Copy file name to clipboardExpand all lines: Chap_Terms.tex
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -30,7 +30,7 @@ \chapter{PMIx Terms and Conventions}
30
30
31
31
\item\declareterm{job} refers to a set of one or more \emph{applications} executed as a single invocation by the user within a session with a unique identifier, the \emph{job ID}, assigned by the \ac{RM} or launcher. For example, the command line ``\textit{mpiexec -n 1 app1 : -n 2 app2}'' generates a single \ac{MPMD} job containing two applications. A user may execute multiple \emph{jobs} within a given session, either sequentially or concurrently.
32
32
33
-
\item\declareterm{namespace} refers to a character string value assigned by the \ac{RM} to a \textit{job}. All \textit{applications} executed as part of that \textit{job} share the same \emph{namespace}. The \emph{namespace} assigned to each \emph{job} must be unique within the scope of the governing \ac{RM} and often is implemented as a string representation of the numerical emph{Job ID}. The \emph{namespace} and \emph{job} terms will be used interchangeably throughout the document.
33
+
\item\declareterm{namespace} refers to a character string value assigned by the \ac{RM} to a \textit{job}. All \textit{applications} executed as part of that \textit{job} share the same \emph{namespace}. The \emph{namespace} assigned to each \emph{job} must be unique within the scope of the governing \ac{RM} and often is implemented as a string representation of the numerical \emph{Job ID}. The \emph{namespace} and \emph{job} terms will be used interchangeably throughout the document.
34
34
35
35
\item\declareterm{application} represents a set of identical, but not necessarily unique,
Many \ac{PMIx} interfaces, particularly nonblocking interfaces, use a \code{(void*)} callback data object passed to the function that is then passed to the associated callback. On the client side, the callback data object is an opaque, client-provided context that the client can pass to a non-blocking call. When the nonblocking call completes, the callback data object is passed back to the client without modification by the \ac{PMIx} library, thus allowing the client to associate a context with that callback. This is useful if there are many outstanding nonblocking calls.
167
167
168
-
A similar model is used for the server module functions (see \ref{server:module_fns}). In this case, the \ac{PMIx} library is making an upcall into its host via the \ac{PMIx} server module callback function and passing a specific callback function pointer and callback data object. The \ac{PMIx} library expects the host to call the cbfunc with the necessary arguments and pass back the original callback data obect upon completing the operation. This gives the server-side \ac{PMIx} library the ability to associate a context with the call back (since multiple operations may be outstanding). The host has no visibility into the contents of the callback data object object, nor is permitted to alter it in any way.
168
+
A similar model is used for the server module functions (see \ref{server:module_fns}). In this case, the \ac{PMIx} library is making an upcall into its host via the \ac{PMIx} server module callback function and passing a specific callback function pointer and callback data object. The \ac{PMIx} library expects the host to call the cbfunc with the necessary arguments and pass back the original callback data obect upon completing the operation. This gives the server-side \ac{PMIx} library the ability to associate a context with the callback (since multiple operations may be outstanding). The host has no visibility into the contents of the callback data object object, nor is permitted to alter it in any way.
0 commit comments