<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
<font size="2"><span style="font-size:11pt" class="ContentPasted0"> >> While it works and means I can avoid predefined handle translations
<br class="ContentPasted0">
in the forward direction, I still have it in the backwards direction, <br class="ContentPasted0">
and it's not exactly simple to resolve all the symbols.<br class="ContentPasted0">
> <br class="ContentPasted0">
> Can you elaborate a bit on the backward translation? I'm not sure I <br class="ContentPasted0">
understand what you mean by that.</span></font></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
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.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
<font size="2"><span style="font-size:11pt" class="ContentPasted1">>> The second question is whether to #define MPI_HANDLE_NULL
<br class="ContentPasted1">
(MPI_Handle*)0. Lisandro argues for this, and it would make a lot of <br class="ContentPasted1">
things easy.</span></font></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
<font size="2"><span style="font-size:11pt" class="ContentPasted1"><br>
</span></font></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
<font size="2"><span style="font-size:11pt" class="ContentPasted1">> <font size="2">
<span style="font-size:11pt" class="ContentPasted2">I believe OMPI uses special null objects for nearly all its null handles
<br class="ContentPasted2">
to avoid checking for NULL on every call.</span></font><br>
</span></font></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
<font size="2"><span style="font-size:11pt" class="ContentPasted1"><br>
</span></font></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
<font size="2"><span style="font-size:11pt" class="ContentPasted1">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.
<br>
</span></font></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
<font size="2"><span style="font-size:11pt" class="ContentPasted1"><br>
</span></font></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
<font size="2"><span style="font-size:11pt" class="ContentPasted1">-- <br>
</span></font></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
<font size="2"><span style="font-size:11pt" class="ContentPasted1">Hui<br>
</span></font></div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> mpiwg-abi <mpiwg-abi-bounces@lists.mpi-forum.org> on behalf of Joseph Schuchart <schuchart@icl.utk.edu><br>
<b>Sent:</b> Monday, February 20, 2023 8:53 AM<br>
<b>To:</b> mpiwg-abi@lists.mpi-forum.org <mpiwg-abi@lists.mpi-forum.org><br>
<b>Subject:</b> Re: [mpiwg-abi] Tuesday (20 February 2023) meeting agenda</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Jeff,<br>
<br>
You said:<br>
<br>
> While it works and means I can avoid predefined handle translations <br>
in the forward direction, I still have it in the backwards direction, <br>
and it's not exactly simple to resolve all the symbols.<br>
<br>
Can you elaborate a bit on the backward translation? I'm not sure I <br>
understand what you mean by that.<br>
<br>
> The second question is whether to #define MPI_HANDLE_NULL <br>
(MPI_Handle*)0. Lisandro argues for this, and it would make a lot of <br>
things easy.<br>
<br>
I believe OMPI uses special null objects for nearly all its null handles <br>
to avoid checking for NULL on every call. A null request handle for <br>
example is a valid input into `MPI_WAIT` and we can get the empty status <br>
from the null request just like we do from any other request. NULL <br>
function pointers (MPI_TYPE_NULL_DELETE_FN) can point to an empty <br>
function that we can simply invoke. NULL pointers require special <br>
treatment, which is tedious and error prone and has UB lurking around <br>
the corner. With null objects, we will never receive (or hand out) an <br>
invalid pointer, which is safe engineering.<br>
<br>
I'm curious what the benefits are from an application's (or middleware) <br>
standpoint?<br>
<br>
Cheers<br>
Joseph<br>
<br>
On 2/20/23 03:55, Jeff Hammond wrote:<br>
> For the meeting tomorrow, I would like you all to consider the following:<br>
><br>
> There is consensus regarding the following to get type safety:<br>
> typedef struct MPI_ABI_Handle * MPI_Handle;<br>
><br>
> We have two choices for predefined handles:<br>
><br>
> Option 1:<br>
> #define MPI_INT (MPI_Datatype)0x3<br>
><br>
> Option 2:<br>
> #define MPI_INT (MPI_Datatype)&MPI_ABI_INT<br>
><br>
> Option 1 relies on implementation defined behavior regarding the <br>
> casting of integers to pointers, but it is safe. Gonzalo and I had a <br>
> long discussion of this, and the only issue is that (intptr_t)MPI_INT <br>
> == 0x3 is not guaranteed to be true, but (intptr_t)MPI_INT == <br>
> (intptr_t)(void*)0x3 is. Both MPICH and Open-MPI already rely on this <br>
> technique for MPI_IN_PLACE, among others.<br>
><br>
> The advantage of Option 1 - assuming we use a sensible set of <br>
> integer values - is that ABI compatibility layers can do translation <br>
> via a table. This is most useful for datatypes, where there are ~100 <br>
> predefined handles, and to a lesser extent ops. For all other <br>
> handles, there are no more than 3 predefined handles (IIRC).<br>
><br>
> Option 2 allows run-time resolution of predefined handles, which I <br>
> thought was good until I implemented it in <br>
> <a href="https://github.com/jeffhammond/mukautuva">https://github.com/jeffhammond/mukautuva</a>. While it works and means I
<br>
> can avoid predefined handle translations in the forward direction, I <br>
> still have it in the backwards direction, and it's not exactly simple <br>
> to resolve all the symbols. I think Hui also implemented this in his <br>
> compatibility layer, although I don't know if he hates it as much as I do.<br>
><br>
> The second question is whether to #define MPI_HANDLE_NULL <br>
> (MPI_Handle*)0. Lisandro argues for this, and it would make a lot of <br>
> things easy.<br>
><br>
> I hope that we can decide these two questions today. For the second <br>
> meeting, we will address predefined integer constants.<br>
><br>
> Jeff<br>
><br>
> -- <br>
> Jeff Hammond<br>
> jeff.science@gmail.com<br>
> <a href="http://jeffhammond.github.io/">http://jeffhammond.github.io/</a><br>
><br>
<br>
-- <br>
mpiwg-abi mailing list<br>
mpiwg-abi@lists.mpi-forum.org<br>
<a href="https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi">https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi</a><br>
</div>
</span></font></div>
</body>
</html>