> 1. remove all nonblocking calls as requested by the Forum.
and in James' minutes:
> => Chapter authors will reconsider how their chapter can survive
> without non-blocking collective operations.
I believe also we have to reconsider, but we have not the order
to remove them at all.
> 4. Replace with "two-face" versions
> 4. Doesn't solve IACCEPT problem (as discussed in previous note).
Yes, but two-face solves all problems with ISPAWN!
Nobody forces us to handle ISPAWN and IACCEPT in the same way!
Therefore for ISPAWN and MPI_ISPAWN_MULTIPLE I propose:
We should have 2 alternatives in the draft for
4.3.4 Nonblocking requests
a) MPI_ISPAWN and MPI_ISPAWN_MULTIPLE as defined in the Jan. draft
b) MPI_SPAWN_START, MPI_SPAWN_END, MPI_SPAWN_MULTIPLE_START and
MPI_SPAWN_MULTIPLE_END with the semantics of the new section
"two-phase collective communication".
And the 3 alternatives to vote: a), or b), or nothing.
What is your opinion about 2-phase and ISPAWN?
And for IACCEPT it seems necessary to have a non-blocking interface
to check whether an additional client tries to connect.
This must not be the full formalism of request handles.
But it can be a mechanism like IPROBE!
Is this an idea worth to think about a little bit more?