> The last version of the chapter has two proposals. The first is what
> we have been working on: having handler functions, etc. The second
> has a proceed function that gets called when the wait is executed.
The 2nd approach doesn't have to be so restrictive to get away from
mandating threads. The handler function can just as easily be called
anytime MPI detects completion of the request _as_long_as_ the user
calls a communicating MPI function (i.e. relaxed progression rule).
It doesn't have to be the MPI_Wait on the particular request.
Correct me if I'm wrong, but currently I see 3 ways to support handlers
in MPI:
1) with threads, "strong" progression rule, no limitations on functions
2) no threads, "strong" progression rule, unacceptable limitations on
functions (i.e. solution rejected by the users) because they are
executed inside a signal handler, and user and library codes don't
know how to protect from each other (don't have access to each
other's locks)
3) no threads, "weak" progression rule (progress when MPI called),
no limitations on functions
So it's the pick-two-out-of-three scenario.
One possible way to go is: "if thread-safe, must support #1, else must
support #3", with an advice to users about the weak progression in #3.
Comments?
--Raja
-=-
Raja Daoud Hewlett-Packard Co.
raja@rsn.hp.com Convex Division