parsec
parsec copied to clipboard
Mark PaRSEC API as noexcept (with exceptions)
Description
With TTG, PaRSEC has gained a C++ frontend and with it some of the issues specific to C++. C++ compilers typically cannot see inside PaRSEC's C interface and thus cannot infer whether function calls will throw an exception or not. PaRSEC being a C API, most functions will never throw (more on that later). We should thus annotate the most parts of the public API with the noexcept
specifier.
Describe the solution you'd like
Similar to the extern C
annotation (BEGIN_C_DECLS
), the PaRSEC API should have a macro that conditionally annotates functions with the noexcept
specifier. In principle, all functions should be annotated that way, with the exception of functions inside which tasks can be executed. Tasks are funclets provided by the user so PaRSEC should at least allow for exceptions to travel from the task through the PaRSEC API into the calling application code where they may be caught. If these functions were annotated with noexcept
the application would terminate regardless of whether a try-catch block was present. Functions such as parsec_context_test
and parsec_context_wait
come to mind here.
I purposefully did not include the hash table functions in the class of functions that may throw exceptions. While call use a user-provided function pointer to compute the hash of an object I think it is a reasonable constraint to require that hash functions never throw (I don't see a good use-case for throwing hash functions).
All other functions such as those related to data structures, atomic operations, and data collections should be marked as noexcept
since they are C-only and do not call any user-provided function.
Describe alternatives you've considered
Leave the current API as it is. A drawback in that case is that the compiler cannot perform certain optimizations since it must assume that exceptions may leak out of the PaRSEC API. For example, certain optimizations in the standard library regarding nothrow move operations (std::vector
is a prominent example) will not be possible anymore. Similarly, the compiler is unable to optimize code paths containing try-catch blocks if it otherwise knew that no exception can be (legally) thrown.
More broadly, we should move towards proper exception handling in TTG in the future. Having noexcept
annotations in the PaRSEC API will be a first step.
Additional context
The noexcept
specifier: https://en.cppreference.com/w/cpp/language/noexcept_spec