Steve
----------------------------------------------------------------------
> * lines 41 and 44: "MPI_Request_complete_fn" and "REQUEST_COMPLETE_FN"
> should be the same spelling for consistency.
> * lines 35 and 37: "MPI_Request_cancel_fn" and "REQUEST_CANCEL_FN" should
> be the same spelling for consistency.
not done. this is consistant with MPI-1 naming of user functions. I
agree it is not what I would have expected but I decided to be
consistent. We can change it if we decide to.
> * line 35: Does MPI_CANCEL_ERROR return MPI_ERR_GR?
clarified text to say
\begchangejan
\mpifunc{MPI\_CANCEL\_ERROR} acts as if it returned
\consti{MPI\_SUCCESS}. This will mark the generalized request as cancelled.
\begin{rationale}
\mpifunc{MPI\_CANCEL\_ERROR} is only expected to be used when no error
recovery is used in a generalized request. If error recovery is
desired then a {\sf cancel\_fn} should be supplied. Thus,
\mpifunc{MPI\_CANCEL\_ERROR} likely to be used when cancelling is
not supported or the callbacks never fail. In this case, it does not
matter what {\sf cancel\_fn} is supplied. The other likely use is
when the user is not recovering from an error. By default, errors on
\consti{MPI\_COMM\_WORLD} are fatal so this error will cause the
program to abort and the value returned by
\mpifunc{MPI\_CANCEL\_ERROR} is not important. If another error
handler is being used on \mpifunc{MPI\_CANCEL\_ERROR} and it permits
the program to continue, it will appear to the user that the
generalized reqeust failed. Since error recovery is not the goal of
this default error handler, this seemed the logical default.
\end{rationale}
\endchangehan
> * line 36: "...of nongeneralized persistent requests" ?
> ^^^^^^^^^^^^^^
I did mean ift for all persistent requests. This is the most general
statement.