I see that the polling based design 7.2.2 may be inefficient, because
MPI would need to periodically call the progress_fn.
The other proposal in 7.1.1 would force me to use threads to implement
nonblocking I/O, even though I may not "need" threads in my
implementation. In general, I would like the use of threads to be an
option, not a requirement.
Therefore, I have a suggestion for a small change in the definition
of 7.1.1 that would not require me to use threads, would not
preclude thread-based implementations either, and would not change any
of the other semantics in 7.1.1.
To implement nonblocking MPI-IO operations, I don't need a push_fn or
progress_fn; the file system does that for me on its own. I only
need to start the operation with a file-system call, and then test for
completion at some point. i.e., I only need a test-function.
If I could provide a test-function to MPI_GR_START, which is called
only by MPI_Test/Wait, 7.1.1 would be fine with me.
The exact semantics would be as follows:
1. A (nonblocking) test_fn added to MPI_GR_Start.
typedef int test_fn(void *extra_state);
Also provide a predefined null function, MPI_NULL_TEST_FN.
2. As 7.1.1 currently stands, MPI_Test/Wait on a generalized request
checks whether MPI_GR_Complete has somehow been called. In the change
I suggest, MPI_Test/Wait will first call the test_fn and then check
whether MPI_GR_Complete has been called.
In the test_fn, the user can call MPI_GR_Complete if the request has
completed.
If the user wants to use threads to handle external events, e.g., if
the external event "needs" its own push_fn, the user can
set the test_fn to be a null function. The thread handling the event
would call MPI_GR_Complete.
If the GR is based only on MPI events, again the existing 7.1.1 mechanism
works by using a null test_function.
3. MPI does not do anything to progress the external event.
4. Test_fn is called only in MPI_Test/Wait.
5. Nothing else in 7.1.1 changes.