[mpi-21] Ballot 4 - Re: MPI_Abort nit

[Rolf Rabenseifner]

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_at_[hidden]
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)