Retain the parent request and trigger events on it

[devreal]

Signed-off-by: Joseph Schuchart schuchart@icl.utk.edu

[bosilca]

My goal was to avoid additional atomic operations, because I don't think that the parent request can disappear before the internal request. It can be freed by the user, but as it is not yet PML complete, it will linger around until completed by the internal request. Thus, no need to manipulate the refcount on it.

Moreover, as this parent request cannot disappear it means it keeps its own reference counts on the communicator and datatype, we can save those as well, but the mechanism is not yet clear to me.

[devreal]

My rationale was that if we want to trigger the PML complete event on the parent request we have to keep it around until the internal request completes. Maybe we don't want this though. Neither the idea of passing around a request that the user a) does not know (if we pass the internal request or the old request as we did up to now); or b) might have free'd (called MPI_Request_free) before the internal request PML-completes are really appealing.Can we trigger the event on an invalid request (like MPI_REQUEST_NULL)? After all, we cannot guarantee consistency at this point...