I don't think we need to add any new semantics here. If we choose to go with a
GR model that only supports non-persistent requests, then MPI_START simply
can't be used with GR's in exactly the same way that it can't be used with
non-persistent pt2pt requests today. If we do choose to support persistent GR's
then the extension for MPI_START is straightforward. Or am I missing your
> 3. The simplified version glosses over the details of cancelling a GR,
> and of invoking the cancel_fn when an error is returned from any of the
> start_fn, advance_fn, or finish_fn. These details in the prior (complex)
> proposals seemed to me to be getting the 'state' of the request correct
> for subsequent MPI_TEST/WAIT/TEST_CANCELLED invocations--i.e., the state
> of a request must be able to return the correct information to the user.
> Would the details of interaction be the same under the simplified proposal?
In the new proposal, the cancel_fn is only called by MPI if the user calls
MPI_CANCEL. If an error is detected from within, say, the advance_fn, then the
user can do whatever they want to with the request, including invoking the
cancel_fn. (I *think* this works...)
> As for whether or not a template model is useful, I have the following
> musings. In my opinion, GRs do not fit the model suggested for persistent
> requests; they are not invoked repeatedly within inner parallel loops
> with the same arguments, at least for implementing MPI-IO functionality.
> Instead, GRs are a means for extending the MPI predefined request forms,
> in much the same way that users are allowed to extend predefined MPI
> Datatypes. That leads to the multiple (complex!) functions that have
> been previously proposed, to allow reuse of forms but in separate
> instantiations. For now, my mind is keyed to using GRs for implementing
> MPI-IO, and a simpler version *may* suffice for that, but this short-
> sightedness disallows other uses not yet dreamt of in my poor philosophy.
Well, yes and no. My own inclination is to only go with the non-persistent
version suggested by Rajeev at this point. If at some later time a clear need
for a persistent GR interface should pop up, we know exactly how to define one.
The reason I'm opposed to defining both versions right away is that persistent
requests are...very annoying to implement. They seem harmless but they really
aren't, for reasons that are often very subtle. (Don't get me started about
> So it seems we must decide if we want extensible request types, and if so,
> proceed as we were before (with as many simplifications as possible!). If
> we don't want extensible request types, then it is reasonable to overload
> existing functions with new semantics.
I'm afraid I don't quite understand what this means - could you please
elaborate a bit more?
-- Eric Salo Silicon Graphics Inc. "Do you know what the (415)933-2998 2011 N. Shoreline Blvd, 8U-802 last Xon said, just email@example.com Mountain View, CA 94043-1389 before he died?"