At first I thought this was a good idea, but now I'm not
so sure. (This message originally started "This is a great idea").
>
> I think that this is a cleaner way of breaking up the functionality, because
> now we have one function that does "A" and one function that does "B", as
> opposed to having one function that does "A" and another that does "A+B".
Unfortunately it's not quite that clean. Drain+Free is more than
the sum of its parts. If you drain+free on an intercommunicator
created by SPAWN, you are guaranteed that an error in the client
cannot crash the server. Drain and Free by themselves do not
have this property.
In order to get the MPI_COMM_DISCONNECT property, you also
have to mandate that there be no MPI operations between
these two collective (see below) operations. So MPI_COMM_FREE
now has to know that the previous MPI call was COMM_DRAIN.
>
> So now let's take a closer look at MPI_COMM_DRAIN(). Does it really need to be
> collective? I'm not convinced that it does.
I think it has to be collective. Otherwise it's impossible make
well-defined the requirement that "all pending communication can
complete". A collective operation defines a "before" and "after",
so we can require that all communication started "before"
matches up. If the operation were not collective, what
would it mean to do an MPI_COMM_DRAIN at A if B does
an isend() to A at "about the same time". That isend()
may be intended for a matching receive *after* the
MPI_COMM_DRAIN.
Bill