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

[Joseph Schuchart]

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