I have been using "handler" semantics on top of MPI for
a couple of years now. This "handler" package is in use
by several applications here at TICAM (http://www.ticam.utexas.edu).
Applying the semantics of my "handler" package to the
MPI_POST_HANDLER, as described in your Chapter 4 draft (2/5/96),
the MPI_POST_HANDLER could only be called for an MPI_Request which is
1) persistent and
2) in an inactive state.
So MPI_POST_HANDLER could be repeatedly called following the
completion of the associated receive or send, but before the
next call to MPI_START.
This also allows a handler to "evolve" in that it may change
its extra_state or even replace itself with another handler
before reactivating the request via MPI_START.
For advice to users, a handler which calls MPI_START on its
own request should make this call immediately prior to the
return statement, as the handler could be re-entered
during the MPI_START call.
There is no question about when a request should be deleted.
The application must explicitly MPI_REQUEST_FREE and is responsible
for only calling MPI_REQUEST_FREE once for a given MPI_Request,
just like any other allocated object in an application.
A call to MPI_CANCEL marks the MPI_Status cancelled and then
invokes the handler. Thus the handler may "clean up" the buffers,
free the request, etc. regardless of how the request terminated.
--Question: Are "handlers" truly "one-sided", as the application must explicitly create or restart a receive to match every send?
---------------------------------------------------------------------------- Carter Edwards, carter@ticam.utexas.edu, http://www.ticam.utexas.edu/~carter ----------------------------------------------------------------------------