MPI_META_REQUEST_START
would be preferable to the other options mentioned so far.
A more fundamental question in my mind is whether or not creating a
meta request is creating a template or type definition for a request,
which is how I read the original proposal. (The META qualifier also
influences this interpretation.) The current proposal is confusing
to me since for persistent requests, it appears to me that a 'type'
does exist, separate from the request(s) that may be instantiated for
any meta request. This has the appeal of defining a set of functions
that can be shared for each instantiation of a request, but each request
has its own unique state, although the current proposal is somewhat
muddled (IMHO) since there is only one state instantiation for each
meta request created.
Having a 'typing' mechanism is appealing, regardless of whether one
wants to have persistent or nonpersistent, blocking or nonblocking, I
think. It is the typing mechanism that expresses the common or shared
facets of a set of requests. It optimizes user interaction in allowing
the user to specify a type once and use it multiple times. But it also
requires the user to perform more work in creating a type, instantiating
the type, and freeing the type when no longer needed. One needs to
decide if the benefits outweigh the costs.
I have some other questions and potential grievances with the current
proposal. My understanding (questionable, at best) is that currently a
nonpersistent GR continues to use the same request handle returned by
the MPI_META_REQUEST_CREATE. After this request has completed, I would
assume that, like other MPI requests, this handle is no longer usable
(i.e., I'd assume it was MPI_REQUEST_NULL after completion). Yet the
example in the proposal indicates that MPI_META_REQUEST_FREE is to be
called with this handle. This needs clarification, which relates again
to whether the handle returned by MPI_META_REQUEST_CREATE is for a type
(meta-request) or a request. This is a lack of symmetry that is very
bothersome to me.
(One other issue to specify is the ordering of execution of the complete
function and a potential 'handler' function posted to a GR, which can
be resolved after these other issues, but I mention it so that it won't
get forgotten.)
I have only read the proposal words and the more recent discussions on
this reflector, so I do not know if these issues have been debated in
meetings and resolved. I will suggest that decisions made are not
clearly represented in the current document, in my opinion, else I would
not be confused by the intent. (OK, I get confused easily, so maybe I
would still be :-)
If the committee decides that there is only one kind of GR and that
a type/instantiation model is not desirable, it seems to me that more
renaming might be warranted, along the lines of:
MPI_GENERAL_REQUEST_CREATE (or INIT ?)
MPI_GENERAL_REQUEST_START
MPI_GENERAL_REQUEST_MARK_COMPLETE
I hope my outsider comments will not be offensive to those who have
wrestled long with these ideas as I only want to improve my understanding
and to help make the intent of the proposal clear!
Linda Stanberry
lstanberry@llnl.gov