<div><div dir="auto">This is going to cause horrible problems. I hate to say it, but the time for MPI to have avoided hidden state was in the 1990s.</div><div dir="auto"><br></div><div dir="auto">Lots of MPI libraries create their own communicator from the compile-time constant rather than a communicator argument. Breaking even a few of these will ruin MPI’s exhalted reputation in the HPC world.</div><div dir="auto"><br></div><div dir="auto">The better option is to provide new headers and libraries for sessions that break backwards compatibility. Or just have users opt-in to sessions by not using MPI_COMM_WORLD at all. That way you’re only breaking code that wants this feature rather than many that don’t.</div><div dir="auto"><br></div><div dir="auto">What’s your Fortran story? If you don’t have a trivial solution for users of mpif.h, you’ve lost approximately half if MPI’s users.</div><div dir="auto"><br></div><div dir="auto">Jeff</div><br><div class="gmail_quote"><div>On Mon, Oct 30, 2017 at 11:33 AM Bland, Wesley <<a href="mailto:wesley.bland@intel.com">wesley.bland@intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word;line-break:after-white-space">
The sessions working group is working on a proposal that, among other things, would change the way MPI_COMM_WORLD works. As much as I don't want to take things out of context for those who aren't familiar with the proposal, I'm not going to summarize the whole
 thing here. If you need that, look here: <a href="https://github.com/mpiwg-sessions/sessions-issues/wiki/sessions_cheat_sheet" target="_blank">https://github.com/mpiwg-sessions/sessions-issues/wiki/sessions_cheat_sheet</a>
<div><br>
</div>
<div>On today's call, we were trying to decide the result of a backward compatibility break for the MPI_COMM_WORLD symbol. We want to keep the MPI_COMM_WORLD symbol to allow legacy codes to work, but we don't want to make it a compiler symbol anymore.
 It would only exist if you call MPI_INIT. To that end, MPI_INIT would look something like this:</div>
<div><br>
</div>
<div><font face="Menlo">MPI_Init(...) {</font></div>
<div><font face="Menlo"><span class="m_-3543274657276370272Apple-tab-span" style="white-space:pre-wrap"></span>MPI_Comm *comm;</font></div>
<div><font face="Menlo"><span class="m_-3543274657276370272Apple-tab-span" style="white-space:pre-wrap"></span>MPI_Session *session;</font></div>
<div><font face="Menlo"><br>
</font></div>
<div><font face="Menlo"><span class="m_-3543274657276370272Apple-tab-span" style="white-space:pre-wrap"></span>MPI_Session_init(..., session);</font></div>
<div><font face="Menlo"><span class="m_-3543274657276370272Apple-tab-span" style="white-space:pre-wrap"></span>MPI_Group_create_from_session_name(&session, "<a>mpi://WOLRD</a>", comm);</font></div>
<div><font face="Menlo"><span class="m_-3543274657276370272Apple-tab-span" style="white-space:pre-wrap"></span>MPI_COMM_WORLD = *comm;</font></div>
<div><font face="Menlo">}</font></div>
<div><br>
</div>
<div>The problem here is that MPI_COMM_WORLD is no longer the compile-time constant that it was before. For example, if you're using MPI_COMM_WORLD in a library, this would cause problems.</div>
<div><br>
</div>
<div>The working group is trying to figure out the results of this to decide whether this would cause horrible problems. It seems that as long as applications are reasonably well behaved and check if the library is initialized first, they should work
 correctly.</div>
<div><br>
</div>
<div>What is this community's opinion of this?</div>
<div><br>
</div>
<div>Thanks,<br>
Wesley</div>
</div>

_______________________________________________<br>
To manage subscription options or unsubscribe:<br>
<a href="https://lists.mpich.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">https://lists.mpich.org/mailman/listinfo/devel</a></blockquote></div></div><div dir="ltr">-- <br></div><div class="gmail_signature" data-smartmail="gmail_signature">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>