[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.


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

More information about the mpiwg-tools mailing list