[mpiwg-abi] Tuesday (20 February 2023) meeting agenda

[Zhou, Hui]

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

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

--
Hui
________________________________
From: mpiwg-abi <mpiwg-abi-bounces at lists.mpi-forum.org> on behalf of Joseph Schuchart <schuchart at icl.utk.edu>
Sent: Monday, February 20, 2023 8:53 AM
To: mpiwg-abi at lists.mpi-forum.org <mpiwg-abi at lists.mpi-forum.org>
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
> jeff.science at gmail.com
> http://jeffhammond.github.io/
>

--
mpiwg-abi mailing list
mpiwg-abi at lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-abi/attachments/20230220/c575628b/attachment-0001.html>