My proposal is a slight modification to Marc's to provide user
specified test/wait functions to determine the completion of an
external event, not to cause progress. It is useful when the external
event has its own progress engine (e.g. file system).
If the user provides a non-null
test/wait function, the MPI implementation must call either one of
those within MPI_Test/MPI_Wait before it checks to see whether
MPI_GR_Complete has been called. In other words, the test_fn/wait_fn
could detect completion and call MPI_GR_Complete.
This allows the user to check for completion of external event,
and not rely only on asynchronous notification via threads or signal
handlers.
*******
Correct me if I am wron, Rajiv, but if I understand correctly
the propsal, it does not add new functionality, but may
allow some optimizations. I assume one will still need an external
progress
engine for I/O and external notification for MPI. Otherwise,
what happens if the user calls MPI_WAIT, and the wait function
returns with the information that the GR is not complete? The user wait
callback cannot block.
If I am right, hen the debate is on the added performance/convenience that
can be
achieved this way, vs the
the inneficiency of a callback occuring for each MPI_TEST call, even if
unsuccesful.
********
> ("Both" means one has to interfaces with different strategies where
> progress can occur, "chosable" means one interface, but the method
> can be choosen.)
>
> Marc's, Rajeev's and the LAST-meeting proposal at least fulfil
> the following requirements
>
> generalized-request progress engine
> event dr. polling both chosable
> MPI event driven Marc/Rajeev Marc
> polling Marc/LAST Rajeev/LAST LAST Marc/Rajeev/LAST
> both Marc Marc
> chosable Marc/LAST LAST LAST Marc/LAST
>
> But we should solve the full matrix.
>
> Possibly I did not unterstand Rajeev's proposal correctly and it
> fulfils all the requirements. -- Please correct me.
>
> Otherwise we should add the missing parts to Marc's proposal
> or combine Marc's with that from the last meeting.
The above table can only be filled if we provide support for progress
on external events, which is a separate debate on its own.
Rajeev
*******
At the risk of repeating myself, I don't beleive that MPI should solve the
general problem of having progress on several
concurrent activities, each of which may involve system calls. The
solution to this problem is called kernel
threads, and there is no reason for MPI to reinvent it, possibly slowing
down the message passing functions.
Marc
*********