<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 20, 2023 at 6:53 PM Zhou, Hui <<a href="mailto:zhouh@anl.gov" target="_blank">zhouh@anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<div 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)">
<font size="2"><span style="font-size:11pt"> >> 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.</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)">
<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)">
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></div></blockquote></div></div></blockquote><div><br></div><div>MPI_GROUP_EMPTY is the valid output for all group manipulation functions (they do not return MPI_GROUP_NULL).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br>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."<span style="font-family:CMR10;font-size:11pt"> </span><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div 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)">
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<font size="2"><span style="font-size:11pt">>> 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.</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)">
<font size="2"><span style="font-size:11pt"><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)">
<font size="2"><span style="font-size:11pt">> <font size="2">
<span style="font-size:11pt">I believe OMPI uses special null objects for nearly all its null handles
<br>
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)">
<font size="2"><span style="font-size:11pt"><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)">
<font size="2"><span style="font-size:11pt">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.</span></font></div></div></div></blockquote></div></div></blockquote><div><br></div><div>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.</div><div><br></div></div></div></div></blockquote><div><br></div><div>Can you give an example of how it’s error prone? What errors is OMPI catching because it’s not null?</div><div><br></div><div>Jeff</div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> George.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Indeed. It would be nice to have zero initialization be equivalent to null handle initialization.</div><div><br></div><div>Jeff </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div 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)"><font size="2"><span style="font-size:11pt">
</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)">
<font size="2"><span style="font-size:11pt">-- <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)">
<font size="2"><span style="font-size:11pt">Hui<br>
</span></font></div>
<div id="m_6997744840926869277m_8042892687275752636appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="m_6997744840926869277m_8042892687275752636divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> mpiwg-abi <<a href="mailto:mpiwg-abi-bounces@lists.mpi-forum.org" target="_blank">mpiwg-abi-bounces@lists.mpi-forum.org</a>> on behalf of Joseph Schuchart <<a href="mailto:schuchart@icl.utk.edu" target="_blank">schuchart@icl.utk.edu</a>><br>
<b>Sent:</b> Monday, February 20, 2023 8:53 AM<br>
<b>To:</b> <a href="mailto:mpiwg-abi@lists.mpi-forum.org" target="_blank">mpiwg-abi@lists.mpi-forum.org</a> <<a href="mailto:mpiwg-abi@lists.mpi-forum.org" target="_blank">mpiwg-abi@lists.mpi-forum.org</a>><br>
<b>Subject:</b> Re: [mpiwg-abi] Tuesday (20 February 2023) meeting agenda</font>
<div> </div>
</div>
<div><font size="2"><span style="font-size:11pt">
<div>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" target="_blank">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>
> <a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br>
> <a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a><br>
><br>
<br>
-- <br>
mpiwg-abi mailing list<br>
<a href="mailto:mpiwg-abi@lists.mpi-forum.org" target="_blank">mpiwg-abi@lists.mpi-forum.org</a><br>
<a href="https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi" target="_blank">https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi</a><br>
</div>
</span></font></div>
</div>
-- <br>
mpiwg-abi mailing list<br>
<a href="mailto:mpiwg-abi@lists.mpi-forum.org" target="_blank">mpiwg-abi@lists.mpi-forum.org</a><br>
<a href="https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi" rel="noreferrer" target="_blank">https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi</a><br>
</div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr">Jeff Hammond<br><a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br><a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a></div></div>
-- <br>
mpiwg-abi mailing list<br>
<a href="mailto:mpiwg-abi@lists.mpi-forum.org" target="_blank">mpiwg-abi@lists.mpi-forum.org</a><br>
<a href="https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi" rel="noreferrer" target="_blank">https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi</a><br>
</blockquote></div></div>
</div></blockquote></body></html>