From: "Rolf Rabenseifner" Date: January 29, 2008 3:06:49 AM CST To: mpi-21@XXXXXXXXXXX Cc: Karl Feind ,"Bill Gropp" ,Andrew Lumsdaine ,Richard Treumann Subject: Ballot 4 - Re: MPI_Abort nit This is a proposal for MPI 2.1, Ballot 4. I'm asking especially Karl Feind, Bill Gropp, Andrew Lumsdaine, Dick Treumann, the participants of the email-discussion in 2001, to review this proposal. This is a follow up to: MPI_Abort in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.html with mail discussion in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discuss/abort/ ___________________________________ Proposal: MPI-1.1 Sect. 7.5, MPI_Abort, page 200, lines 23-26 read: This routine makes a "best attempt" to abort all tasks in the group of comm. This function does not require that the invoking environment take any action with the error code. However, a Unix or POSIX environment should handle this as a return errorcode from the main program or an abort(errorcode). but should read (" or an abort(errorcode)" removed): This routine makes a "best attempt" to abort all tasks in the group of comm. This function does not require that the invoking environment take any action with the error code. However, a Unix or POSIX environment should handle this as a return errorcode from the main program. ___________________________________ Rationale for this clarification: POSIX defines void abort(void). The routine void exit(int status) may be used to implement "handle this as a return errorcode from the main program". abort(errorcode) was not substituted by exit(errorcode) because this is technically not enough, if the MPI implementation wants to return it also from mpiexec, see next proposal. ___________________________________ Proposal: Add after MPI-1.1 Sect. 7.5, MPI_Abort, page 200, line 34 (end of rationale): Advice to users. Whether the errorcode is returned from the executable or from the MPI process startup mechanism (e.g., mpiexec), is an aspect of quality of the MPI library but not mandatory. (End of advice to users.) ___________________________________ Rationale for this clarification: The intent of word "should" in "should handle this as a return errorcode from the main program" is only a quality of implementation aspect and not a must. This is not clear and can be misinterpreted. ___________________________________ Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner@XXXXXXX High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)