Handling error conditions in libgomp

[Nathan Sidwell]

On 02/28/14 16:05, Richard Henderson wrote:

> I'd be ok with some kind of registration interface, like
>
>    old = omp_set_error_handler (new);
>
> so that a library can set and restore the handler around its own omp usage.

I agree.  An explicit API should be exposed to do this.

> As for the interface of the handler itself...  I dunno.  I'd hate to make it
> too complicated to actually use.  If severity is restricted to a single bit
> meaning "cannot possibly continue" or "transient error".  Maybe with the error
> string, since who knows what kind of weirdness is going on in the plugin.

I wonder whether there should be 2 separate handlers -- one for the diagnostic 
and one for fatality?  Something like:

typedef void omp_diag_t (void *usr_data, unsigned flags, const char *, va_list);

void *OMP_diag_data;
omp_diag_t *OMP_diag_fn = OMP_diag_default;
void (*OMP_fatal_fn) (void) = abort;

then in gomp:
void OMP_error (unsigned flags, const char *fmt, ...) {
   va_list args;
   ...
   OMP_diag_fn (OMP_diag_data, flags, fmt, args);
}

void __attribute__ ((noreturn))
OMP_fatal (const char *fmt, ...) {
   ...
   OMP_diag_fn (OMP_diag_data, SOMETHING, fmt, args);
   OMP_fatal_fn ();
}

That way the non-returning nature of OMP_fatal can be exposed to the compiler 
(I'm sure that'll kill a lot of false positive compiler warnings).

nathan

-- 
Nathan Sidwell