Re: MPI_Abort

[Janne Blomqvist <blomqvist dot janne at gmail dot com>]

On Wed, Jul 13, 2011 at 18:09, Tobias Burnus <burnus@net-b.de> wrote:
> However, I wonder about the exit status code. Under Unix, one has 0 for
> success and >0 for an error. Under Windows, it's similar, but "exit(3)" is
> regarded as abort. While an abort might be OK - one also get's with gfortran
> on some platforms a backtrace, one should better just use "exit(1)" or
> directly abort().
>
> Currently, STAT_STOPPED_IMAGE has the value 3. Thus, it might be better to
> just use "1".
>
> (Cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47394 for using exit(3) on
> Windows.)

As an aside, C defines, in stdlib.h, the macros EXIT_SUCCESS and
EXIT_FAILURE. Typically the values will be 0 and 1, respectively, so
the end result would be the same as using 1 and 0 directly as we do
now. I suppose they were added in order to improve portability, though
I suspect in reality it doesn't make much difference.

> Actually, the gfortran library has a similar "problem";
> libgfortran/runtime/error.c uses:
>
> Â* The following exit conditions are defined:
> Â* 0 Â ÂNormal program exit.
> Â* 1 Â ÂTerminated because of operating system error.
> Â* 2 Â ÂError in the runtime library
> Â* 3 Â ÂInternal error in runtime library
>
> Well, using abort for the latter can be regarded as acceptable, though also
> there an explicit "abort()" would be better.

Considering this isn't documented anywhere except in the comment you
copy-pasted, I suspect in reality we might as well just use only 1 for
error termination status in libgfortran. The error message printed to
stderr should in any case hopefully be more specific as to what caused
the error termination.

Another thing is runtime/error.c (recursion_check). This function is
obviously thread-unsafe. I suspect we might be better off just
removing it altogether and accept that we might get multiple error
messages printed if several threads are simultaneously in the process
of exiting due to some error.

-- 
Janne Blomqvist