1) HANDLERS and WAIT -- it is needed!
There is a need to "wait" for a request with an attached
communication handler. In my application I test an
flag in "extra_state". If the flag is not set I wait
for the request to complete. After the "wait" subprogram
returns the "status" information has already been processed
by the handler, and is not needed.
=>
a) Calling "wait" for the request is needed.
b) Having the "wait" return an empty status value is acceptable.
An example code fragment:
if ( extra_state->flag == 0 ) {
MPI_Status dummy ; /* No value required */
MPI_Wait( &extra_state->request , &dummy );
}
/* extra_state->flag is now 1 */
and a very dangerous alternative:
while ( extra_state->flag == 0 );
How does MPI regain control to complete the request in
a non-threaded environment?
2) (effectively) nonpersistent requests with handlers
A handler which calls MPI_REQUEST_FREE for its request
has effectively made the persistent request into a
nonpersistent request via the handler. MPI could provide
the user with an MPI_HANDLER_FREE handler for this purpose.
3) MPI_HANDLER_NULL handler
An MPI defined constant such that a call to MPI_POST_HANDLER
with "handler = MPI_HANDLER_NULL" essentially deletes
the handler from the request. The request becomes an
ordinary persistent communication request.
4) HANDLERS and BARRIER -- my misunderstanding
My concern is with the interaction between handlers and
MPI_Barriers in a non-threaded environment.
If a process (in non-threaded environment) is "blocked" on an
MPI_Barrier will continue to complete asynchronous requests and
execute handlers then all-is-well.
I guess my concept of "blocked" in a non-threaded environment
was a little to rigid.
----------------------------------------------------------------------------
Carter Edwards, carter@ticam.utexas.edu, http://www.ticam.utexas.edu/~carter
----------------------------------------------------------------------------