After sitting through many discussions on GR with implementors, I
think the polling based design (7.2.2 aternative of Marc's writeup and
the current one in document) is unlikely to get the support of
everyone. The new proposal (7.1) is based on limited discussions at
the meeting but was at least well received in the basic idea. Thus, I
agree with Marc that we need to flush it out.
The count and array_of_request is very much like a much earlier GR
proposal. Ultimetly we gave up on this interface. The main headache
I remember is that you start with an array_of_requests and each time
the callback completes it can give a new list of array_of_requests.
What is the meaning of the index passed to the callback of the
completed request? Is it some master index, or an index on one of the
lists in which case it is hard to know which list. I would like to
throw out an alternative. The current proposal has two modes:
progress when a request completes and external to MPI. The former is
what is being considered here. These are basically handlers. Would
it make more sense to attach a handler to request and use the
extra_state to allow the user to sort as needed? In this senario the
progress_fn goes away. Also, MPI_GR_CONTINUE is gone since you simply
start up a handler whenever you want. The only requirement is that
MPI_GR_COMPLETE must get called somewhere. The issue of allowing GRs
on the progress list becomes one of deciding if a handler can be
attached to a GR.
There was an alternative discussion of how to handle cancelling which
Marc was not present for. I will send that out soon. The issue of
cancel seems mostly orthogonal to this big decision.
Marc correctly raised the point of calling complete_fn from
MPI_REQUEST_GET_STATUS. This raises the ugly point that complete_fn
can be called multiple times for the same request. (It was already
true because of MPI_TEST but we never discussed it.) At a minimum we
should note this.
I am not clear how MPI_GR_LOCK/UNLOCK work. The text says you should
not call them from inside the progess_fn. How then can you protect
critical sections in the progress_fn?
Steve