<div dir="ltr">All,<div><br></div><div>Thanks for your feedback.  Here is a new draft of the slides.  I tried to capture all of the discussion on this thread, but may have missed some things.  Please feel free to update the slides directly.</div><div><br></div><div>Cheers,</div><div> ~Jim.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 22, 2015 at 1:22 PM, Balaji, Pavan <span dir="ltr"><<a href="mailto:balaji@anl.gov" target="_blank">balaji@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
If this proposal is being put forward, there needs to be a thorough discussion of why info keys are not sufficient.  Inheritance is an issue but the semantics part is being misunderstood, IMO.<br>
<br>
The user hinting that some functionality of MPI will not be used is not a change of semantics for the MPI implementation.  It is simply the user telling the MPI implementation that she does not need the full generality of the MPI standard in that particular instance.  The MPI implementation does not even need to honor that hint.  The "mpi_no_locks" hint in RMA is an example of that (there are other such hints as well).<br>
<br>
So before we go too far down this path, we need to understand what exactly the info model is lacking.  If inheritance is the only issue, there are other alternatives we could pursue.  If we say that MPI info cannot be used to restrict functionality in the MPI implementation, then many hints in the standard need to be removed (which is not backward compatible).  We cannot leave those in the standard *and* say that info semantics don't allow them.<br>
<br>
  -- Pavan<br>
<div><div class="h5"><br>
> On Feb 20, 2015, at 8:00 PM, Jim Dinan <<a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a>> wrote:<br>
><br>
> Hi All,<br>
><br>
> I would like to raise communicator assertions (was communicator info keys) for discussion again at the upcoming meeting.  I have attached a rough sketch of two possible directions for the proposal.<br>
><br>
> The goal with these slides is to create an outline that can be used for discussion in the P2P WG meeting.  Please send feedback, rotten tomatoes, or questions.<br>
><br>
> Cheers,<br>
>  ~Jim.<br>
</div></div>> <MPI Communicator Assertions Straw Man.pdf>_______________________________________________<br>
> mpiwg-p2p mailing list<br>
> <a href="mailto:mpiwg-p2p@lists.mpi-forum.org">mpiwg-p2p@lists.mpi-forum.org</a><br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p</a><br>
<br>
--<br>
Pavan Balaji  ✉️<br>
<a href="http://www.mcs.anl.gov/~balaji" target="_blank">http://www.mcs.anl.gov/~balaji</a><br>
<br>
_______________________________________________<br>
mpiwg-p2p mailing list<br>
<a href="mailto:mpiwg-p2p@lists.mpi-forum.org">mpiwg-p2p@lists.mpi-forum.org</a><br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p</a></blockquote></div><br></div>