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" <[email protected]> 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?