Hi! Currently when libgomp hits an error (that is, an internal error, possibly due to the user doing "stupid" things), after printing a message libgomp/error.c:gomp_fatal terminates the executing process:
void
gomp_fatal (const char *fmt, ...)
{
va_list list;
va_start (list, fmt);
gomp_verror (fmt, list);
va_end (list);
exit (EXIT_FAILURE);
}
The process cannot recover from this, trying to continue despite the
error. (It is of course questionable what exactly to do in this case, as
libgomp's internal state may now be corrupt.) So far, such errors may
have been rare (aside from real bugs, only/primarily dynamic resource
exhaustion?), but in the advent of libgomp using external modules (plugin
interface, for acceleration devices) I expect them to become more
frequent.
That aside, it is also an hurdle for ourselves if in libgomp's testsuite
we want to test that the library does the right thing (abort) for
non-sensible requests.
Does it make sense to add the option for the user to install a handler
for this? Three quick ideas, all untested: generally use abort in
libgomp, which can then be caught with a SIGABRT handler that the user
has set up (difficult to communicate information from libgomp to the
handler); adding a weak function GOMP_error that the user can provide and
that libgomp will call in presence of an error; or provide some GOMP_init
function for registering an error handler. The actual interface might be
something like: an enum to indicate the class (severity?) of the error, a
const char* for an error message that libgomp has generated (possibly
forwarded from a plugin), and a boolean return value to tell libgomp to
either continue or terminate the process. Then, also libgomp's internal
initialization could be made more explicit, so that it can (be)
reinitialize(d) after an error occured. It makes sense that the default
remains to terminate the process in presence of an error.
I have not yet researched what other OpenACC or OpenMP implementations
are doing, or other compiler support/runtime libraries.
Thoughts?
Grüße,
Thomas
pgplDFDltggmv.pgp
Description: PGP signature
