> Or am I hopelessly missing the point again?
> ****
> You are missing the case where progress has to occur while the user code is
> blocked in an MPI_WAIT call: the user cannot invoke push_fn.
> *******
I don't think I'm missing this case, but I AM putting it squarely in the
user's domain to solve. It seems to me that if the user is responsible
for the asynchronous behavior that would be provided by MPI (e.g.,, when
an MPI_Isend is followed by an MPI_Wait), the user must provide the
asynchronous call to the push_fn. This implies to me that there must
be another (logical) thread of execution that the user provides to do
this. That may require that GRs that are user-driven are only allowed in
MPI environments that support threads, which is a simpler rule than the
others in the current proposal, I think.
> *****
> One more remark: I certainly don't want casual users to use this function
> -- it's too easy to screw up performance, if not correctness. It's like
> extensible kernels: we don't expect asual users to extend kernels, and we
> don't expect casual users to extend MPI. GR are in the external chapters
> and are there for the use of library developers.
I think this is terribly short-sighted. Unfortunately, I have to rush
off to a meeting, but the jist of what I want to say is, if you aren't
inventing this for general use, don't bother to put it in the spec. If
you solve the problems for the general public, they will appreciate the
fact that the library developers will produce more robust extensions
for them!
More later...
Linda