There has been a consistency argument that it should be legit to
free a GR request handle because it is legit to free a regular request
without a wait/test. Not so. We already tell the user that the
request from an MPI_Irecv must be wait/tested rather than freed. In
some implementations of MPI, the user could look at the message buffer
and be assured the MPI_Irecv in done once the last byte of the buffer
changes. Still, MPI does not say "go ahead and free Irecv requests if
the implementation of MPI you use has another way to determine the
operation is complete." MPI simply says don't do because, in general
there is no way to verify operation completion.
The GR is both similar and different. The author of the functions
which define the GR must document whether it is like an Irecv and
therefor must be waited or like an Isend and can therefor be freed.
If the author's intent is that it can be freed then he must also
document how the user can know when its operations are complete.
The net is that even if MPI allows MPI_REQUEST_FREE on any GR it
will be awkward for the user to decide exactly when it is really
proper to do.
There is no doubt that I can provide code in my MPI implementation
which will support exactly what Rolf and Marc suggest. The issue
is whether allowing an MPI_REQUEST_FREE on a GR is worth breaking
and otherwise clean semantic.
If the Forum concludes it should do this then there should at the
least be a rationale which says explicity that this is ugly but
justified. Also, that it does not alter the general principle that
keeping copies of object handles is poor practice.
Regards - Dick
Dick Treumann IBM RS/6000 Division
(Internet) treumann@pok.ibm.com Poughkeepsie, NY
(VNET) TREUMANN at KGNVMC Tel: (914) 433-7846
(internal) treumann@windsurf.pok.ibm.com Fax: (914) 433-8363