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. 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). 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. -- Pavan
On Feb 20, 2015, at 8:00 PM, Jim Dinan <[email protected]> wrote:
Hi All,
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.
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.
Cheers, ~Jim. <MPI Communicator Assertions Straw Man.pdf>_______________________________________________ mpiwg-p2p mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p
-- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji