And both proposals do not solve the following problem:
Progress on the general request can be achived only by polling on
an interface outside of MPI, and
the application calls e.g. a collective MPI function, and
progress must be done on the generalized request while the MPI
function is executing (otherwise the application e.g. gets a deadlock).
In Marc's proposal I do not see how the polling on the external
interface can be done.
********
If the user expects to poll on a non MPI event while a blocking MPI call
occurs,
then the user should require his or her vendor to support threads. One
thread
will execute the collective call, and another thread will poll. The kernel
will interleave execution of both threads. Threads are
the standard mechanism that allows interleaved execution of several
computations,
e.g., an MPI call and polling on another event. This is
especially true if we want the polling thread not to be restricted in the
kind
of system calls it can execute. Here, again, we try to reinvent OS
infrastructure. I propose that we agree that MPI hould not try to solve
all the
problems that multithreading is supposed to solve.
**********