parsec icon indicating copy to clipboard operation
parsec copied to clipboard

Mark PaRSEC API as noexcept (with exceptions)

Open devreal opened this issue 2 years ago • 7 comments

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

devreal avatar Mar 21 '22 14:03 devreal