Fair enough. My own take on this is that every decent MPI-1 implementation must
already have a fairly sophisticated progress engine somewhere in its innards.
While specific details vary, many of them look *very* similar. So rather than
mandating a whole new set of functionality that must be pushed down into each
library, I'd prefer to see the mechanims that already exist in current
implementations simply be moved up to where the users can make use of them.
That is the essence of the proposal that Raja posted. I don't think it is an
exaggeration to say that I could probably implement it on top of my current
progress engine in a single afternoon.
> I see GRs as the most powerful tool in MPI if it truly lets users define
> their own request types. If so, it needs to be designed to coexist with all
> existent MPI request types, and not just some (e.g., should support both
> persistent and nonpersistent requests).
I don't think this quite follows. In MPI today, it is not possible to take a
request handle that you obtained from (for example) MPI_ISEND and then pass it
to MPI_START. I do agree that the GRs should coexist as much as possible with
what we already have, but I think that is probably orthogonal to the question
of persistent vs. non-persistent.
> * The 'state' of a request; some means will be necessary to determine if
> a given request is a 'generalized' request so that MPI can perform the
> semantics for GRs in addition to or instead of ordinary MPI_Request
Not if the GR interface is properly designed! IMHO it should be possible to
implement the pt2pt requests that we support today directly on top of any new
GR interface. When you call MPI_ISEND, for example, MPI could simply build a GR
internally with an approporiate start_fn, advance_fn, etc. for pt2pt messages.
In fact that is almost certainly how we would first implement the GR interface,
which may or may not be tuned later on for some special cases.
-- 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?"