<html><body>
<p>Since an assertion is a statement about the application, made by the application, I see no need for a query system that preceeds making the assertion. If the application author is confident enough about the way his application works to make one of the few predefined assertions, it can never do any harm to make the assertion. <br>
<br>
If he wants to experiment, he can use the query function within the application to find out if the assertion he made is being exploited by the MPI implementation. If the query function says the assertion is not being exploited then it is harmless. If the query function says it is being exploited then the application author can try his application with and without the assertion to see if the payoff is noticable. If he is the cautious type he can put in a query and issue a warning for any MPI implementation that exploits the assertion. The warning would say "Additional testing may be required". When he changes or upgrades his MPI and the new MPI implementation does exploit the assertion he will be warned.<br>
<br>
I think if there are more than a very few assertions available, the third party libraries will simply take the defensive actions of disallowing all assertions. If there are a very few will defined assertions, third party libraries can decide which ones to allow.<br>
<br>
If there are a small number of predefined assertion there is no reason the standard could not say which bit each one uses. If the standard said MPI_NO_EAGER_THROTTLE was to be 0x01 there would be no ABI issue.<br>
<br>
<br>
Dick Treumann - MPI Team/TCEM <br>
IBM Systems & Technology Group<br>
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
Tele (845) 433-7846 Fax (845) 433-8363<br>
<br>
<br>
<tt>mpi3-subsetting-bounces@lists.mpi-forum.org wrote on 06/20/2008 01:05:03 PM:<br>
<br>
> <br>
> Yes, but the best approach would be a query/subscribe<br>
> interface, possibly with some set of standard ketwords<br>
> that provide portability.<br>
> <br>
</tt></body></html>