It is not clear to me, in this proposal, how MPI figures out which callback function it should
invoke when a registered request completes. I would suggest to provide this information with
the registration. This may also make registration id's superfluous. Thus
MPI_REQUEST_REGISTER(request, extra_state, comm, status, callback_fn).
When the communication request ``request'' completes, MPI sets ``status'' and
invokes ``callback_func'' with arguments request, extra_state, comm.
No changes in the definitions of
The continue function is of type
typedef int MPI_Request_continue_fn(MPI_Comm comm, MPI_Request request, void *extra_state,
MPI_Status *status, int *flag);
``comm'' is the communicator used for the user defined operation (the argument in the call to
MPI_Request_init), and ``request'' is the request returned by the call to MPI_Request_init;
``extra_state'' is whatever was returned by the previous call to Request_continue (or by the
call to Request_start, if none). ``status'' is the status for the communication that just
completed. (If people believe they need an additional identification for the request that
completed, we can add back the id in Request_register, and have it as an input parameter to
Request_continue). ``flag'' returns 0 if the user-defined operation has not completed yet, 1
if it has completed. I.e., it is the user's responsibility (in its Request_continue code), to
figure out if the user-defined operation has completed, not MPI's. This avoids the need for a
reverse index (one needs to hold for each registered request a pointer to the callback function,
but one does not need for each callback function to hold the set of active registered
communications). My take is that it should be pretty easy for the user to keep track of the
calls that were initiated as part of the execution of user-defined request;
the logic of the program will require hinm/her to do so, anyhow.
Therefore, there is no reason to have MPI keep track of this information.