Several people have now commented on this ordering. I deliberately
left it vague to see what people would say. The one thing that is
clear from the discussion is that people want some statement about
ordering that is less vague. I suggest we agree on one and put it in
to see if implementors complain.
I now propose to state that the complete_fn will fire first and then
the handler. One can make arguments for the reverse order too (as has
been done). Here is my reasoning. On a regular request, the handler
fires once the request is complete but before the wait/test completes.
I think it is reasonable for the handler to take the supplied request
and use MPI_GET_STATUS to look at the status of the request. One
expects all the fields that will ever be filled in to be available at
this time since the request has completed. To carry this over to GR,
the complete_fn must have executed for the status to be filled in.
This is why I propose the complete_fn goes first and then the handler.
> As a very minor issue, I wondered why MPI_GR_INIT (OK, so I'm the person
> who mentioned it!) instead of MPI_GR_CREATE, and why MPI_GR_BEGIN
> instead of MPI_GR_START were chosen. I really don't have an opinion but I
> note that most MPI stuff that is FREEd was first CREATEd, and that requests
> are STARTed. However, either naming works for me :-)
I do not have strong opinions about this. I went away from previously
used names since the functionality is similar but different. I was
afraid that people would think it would have the same syntax and
semantics when it is actually a little different. Others have opinions?
> As another minor issue, should we use MPI_GR_MARK_COMPLETE instead of
> MPI_MARK_REQUEST_COMPLETE?
Yes, I forgot to do this one. I agree this name is better.
Steve