My understanding of the vote was that we basically wanted
to see what the consequences would be to taking them out.
What I'd like to do to implement that is take them out
in this early draft (this is only the first cut) and
see what the reaction is.
>
> > 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".
I believe the discussion in the collective committee concluded
that this mechanism would work, but that we didn't want to
automatically add this syntax to replace every nonblocking collective
call. Instead we wanted to add it carefully, only where there
was a very clear reason and benefit. So perhaps we can try
to focus the discussion on whether there is a clear benefit
rather than on whether it's possible to do it (I agree it's
possible).
Since it's a fairly large block of text to write up, I won't
be able to put it in the document for tomorrow, but let's
discuss the pros and cons over the next couple of weeks.
> 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?
Agreed. We need to have
such a mechanism. Based on previous discussion about
IPROBE and company, I think the right approach
is something like MPI_TRYACCEPT, which is basically
a nonblocking ACCEPT (in the normal sense, not
the MPI sense) that either accepts or not, and returns
an additional TRUE/FALSE flag.
Eric mentioned this as well and it didn't click the first
time. It would have been nice to avoid the additional
function. (We could still avoid it with MPI_JOIN).
Bill