[mpiwg-tools] question about MPI_T_EVENT_SET_DROPPED_HANDLER
Raffenetti, Kenneth J.
raffenet at mcs.anl.gov
Tue Jan 26 14:24:32 CST 2021
To me, option 1 makes the most sense from both an implementation and user perspective. Explicit and unsurprising. But yes, we may be constrained on time. Worst, IMO, is option 3, which on the user side would require some complex logic to even know what user_data pointer the dropped handler is providing.
Options 2 and 4 are somewhere in the middle. Not ideal, but might be an effective hedge.
Ken
On 1/26/21, 11:29 AM, "Marc-André Hermanns" <hermanns at itc.rwth-aachen.de> wrote:
There could be different solutions for this situation, and each of
them has a problem in our current situation:
1) Add a "user_data" element to the "dropped_handler" registration call.
2) If the MPI implementation does not support a certain level at all,
have the callback registration function return MPI_T_ERR_NOT_SUPPORTED
and refuse the registration in this case.
3) Use the 'user_data' registered with a callback at a safety level
closest to the one where the dropped handler is invoked with.
4) Just accept that the dropped handler will never be called in this case.
Option 1 would be in symmetry with the "free" handler registration,
but would need an API change and a no-no vote to be included in 4.0.
Is that likely to happen?
Option 2 would be possible, yet MPI_T_ERR_NOT_SUPPORTED is not yet
listed in Table 15.7 on page 778 in the correct row (it exists, but is
listed only for MPI_T_SOURCE_*) ... We might handle this as an
oversight and clarify it basically with the release of MPI 4.0 and
include it in 4.1.
Option 3 feels odd, as the we assume something about the
characteristics of 'user_data' for a safety level that might not be
the case and might not be safe.
Option 4 would be possible, yet lacks the feedback to the user that
something went wrong.
What's your opinion? Are there other/better ways to deal with the
situation?
More information about the mpiwg-tools
mailing list