> - remove the alternative proposal
OK. My assumption was that communication handlers had gone entirely,
which is not the case now.
> - The progress/semantics are defined by the handlers that Marc has
> written up. I think what we would like is:
> 1) If your implementation has threads then your request progresses
> without any MPI calls on that process.
>
> 2) If you are emulating threads, then your request may only progress
> if you call an MPI function. Also, issuing a blocking call in your
> handler is likely to hang your code.
I agree. This automatically requires an inquiry function/attribute for
telling which case is true for an implementation.
> - Koichi indicated in mail that he felt that the complete_fn can be
> dropped. I'm afraid I don't see why. If you call lots of concurrent
> handlers within one generalized request, then how does MPI know when
> the request is done? We previously tried to keep lists of requests
> but decided against this. I'm afraid I may be missing something.
In my view of the current main proposal, any progress for a
generalized request is made by handlers posted on subrequests on the
GR. The handlers checks the completion of the entire GR, then one of
them calls MPI_Request_mark_complete.
I see, however, that it may be better for the status to be set in
complete_fn than in a handler for one of the subrequests of a GR.
I do not understand what is the problem with calling lots of concurrent
handlers and keeping lists of requests.
-Koichi