On Mon, Feb 20, 2023 at 12:08 PM Jeff Hammond <[email protected]> wrote:
On Mon, Feb 20, 2023 at 6:53 PM Zhou, Hui <[email protected]> wrote:
While it works and means I can avoid predefined handle translations in the forward direction, I still have it in the backwards direction, and it's not exactly simple to resolve all the symbols.
Can you elaborate a bit on the backward translation? I'm not sure I understand what you mean by that.
I think Jeff meant for output parameters such as in MPI_Comm_create. I believe all handle constants are input only except for NULL handles.
MPI_GROUP_EMPTY is the valid output for all group manipulation functions (they do not return MPI_GROUP_NULL).
Yeah, NULL handle outputs, but also MPI_Type_get_contents, because "If these were predefined datatypes, then the returned datatype is equal to that (constant) predefined datatype and cannot be freed."
The second question is whether to #define MPI_HANDLE_NULL (MPI_Handle*)0. Lisandro argues for this, and it would make a lot of things easy.
I believe OMPI uses special null objects for nearly all its null handles to avoid checking for NULL on every call.
From the user's point of view, using 0 as NULL is convenient. Uninitialized static variables are zero-filled. It is also convenient to zero-fill an array.
Convenient but error prone. If users want a NULL object they need to set it clearly, not rely on assumptions about zero-filled memory regions. OMPI has been doing this for years and no users complained, because it is good practice. George.
Indeed. It would be nice to have zero initialization be equivalent to null handle initialization.
Jeff
-- Hui ------------------------------ *From:* mpiwg-abi <[email protected]> on behalf of Joseph Schuchart <[email protected]> *Sent:* Monday, February 20, 2023 8:53 AM *To:* [email protected] <[email protected]> *Subject:* Re: [mpiwg-abi] Tuesday (20 February 2023) meeting agenda
Jeff,
You said:
While it works and means I can avoid predefined handle translations in the forward direction, I still have it in the backwards direction, and it's not exactly simple to resolve all the symbols.
Can you elaborate a bit on the backward translation? I'm not sure I understand what you mean by that.
The second question is whether to #define MPI_HANDLE_NULL (MPI_Handle*)0. Lisandro argues for this, and it would make a lot of things easy.
I believe OMPI uses special null objects for nearly all its null handles to avoid checking for NULL on every call. A null request handle for example is a valid input into `MPI_WAIT` and we can get the empty status from the null request just like we do from any other request. NULL function pointers (MPI_TYPE_NULL_DELETE_FN) can point to an empty function that we can simply invoke. NULL pointers require special treatment, which is tedious and error prone and has UB lurking around the corner. With null objects, we will never receive (or hand out) an invalid pointer, which is safe engineering.
I'm curious what the benefits are from an application's (or middleware) standpoint?
Cheers Joseph
On 2/20/23 03:55, Jeff Hammond wrote:
For the meeting tomorrow, I would like you all to consider the following:
There is consensus regarding the following to get type safety: typedef struct MPI_ABI_Handle * MPI_Handle;
We have two choices for predefined handles:
Option 1: #define MPI_INT (MPI_Datatype)0x3
Option 2: #define MPI_INT (MPI_Datatype)&MPI_ABI_INT
Option 1 relies on implementation defined behavior regarding the casting of integers to pointers, but it is safe. Gonzalo and I had a long discussion of this, and the only issue is that (intptr_t)MPI_INT == 0x3 is not guaranteed to be true, but (intptr_t)MPI_INT == (intptr_t)(void*)0x3 is. Both MPICH and Open-MPI already rely on this technique for MPI_IN_PLACE, among others.
The advantage of Option 1 - assuming we use a sensible set of integer values - is that ABI compatibility layers can do translation via a table. This is most useful for datatypes, where there are ~100 predefined handles, and to a lesser extent ops. For all other handles, there are no more than 3 predefined handles (IIRC).
Option 2 allows run-time resolution of predefined handles, which I thought was good until I implemented it in https://github.com/jeffhammond/mukautuva. While it works and means I can avoid predefined handle translations in the forward direction, I still have it in the backwards direction, and it's not exactly simple to resolve all the symbols. I think Hui also implemented this in his compatibility layer, although I don't know if he hates it as much as I do.
The second question is whether to #define MPI_HANDLE_NULL (MPI_Handle*)0. Lisandro argues for this, and it would make a lot of things easy.
I hope that we can decide these two questions today. For the second meeting, we will address predefined integer constants.
Jeff
-- Jeff Hammond [email protected] http://jeffhammond.github.io/
-- mpiwg-abi mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi -- mpiwg-abi mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi
-- Jeff Hammond [email protected] http://jeffhammond.github.io/ -- mpiwg-abi mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi