On Fri, 2014-02-28 at 12:37 +0100, Thomas Schwinge wrote: > Does it make sense to add the option for the user to install a handler > for this?
The problem with calling a handler is that it's often hard to define which state the program is in during the handler. If libgomp had to terminate because of a programming error, there's often little one can do anyway to resolve the problem; even proper cleanup could be hard because the program may still hold locks (or violate other invariants) that are necessary for meaningful cleanup. Another problem is that if you specify that a handler is called, then you typically have to always call the handler in an erroneous situation. Thus, I think it would be good to differentiate between different classes of problems. For example, if it's a plugin initialization that's implicit in some lambda construct, then a handler might work, but offering a separate function that triggers such initialization and returns an error might be even better; with such a function, the programmer can do error handling up front. In contrast, for programming errors, simply terminating would be fine for me. At least for C/C++ there's plenty of undefined behavior, so trying to do something better for OpenMP might not be as helpful. > I have not yet researched what other OpenACC or OpenMP implementations > are doing, or other compiler support/runtime libraries. I suggest to also have a look at what proposed C++ parallelism abstractions do. They essentially return exceptions from user-supplied code as a list of exceptions, which is returned (or thrown) by the construct that spawned the parallel execution; translating this to handlers, the thread that spawned the construct should execute any handler. However, part of the problem is certainly OpenMPs goal to provide unified abstractions that work the same in all 3 base languages, which isn't too helpful if considering that those languages have different mechanisms for error handling (e.g., C++ exceptions vs. error codes in C).
