The C++ 2011 std::call_once function is specified to allow
the initialization routine to exit by throwing an exception.
Such an execution, termed exceptional, requires call_once to
propagate the exception to its caller. A program may contain
any number of exceptional executions but only one returning
execution (which, if it exists, must be the last execution
with the same once flag).
On POSIX systems such as Linux std::call_once is implemented
in terms of pthread_once. However, as discussed in libstdc++
bug 66146 - "call_once not C++11-compliant on ppc64le," GLIBC's
pthread_once hangs when the initialization function exits by
throwing an exception on at least arm and ppc64 (though
apparently not on x86_64). This effectively prevents call_once
from conforming to the C++ requirements since there doesn't
appear to be a thread-safe way to work around this problem in
libstdc++.
The attached patch changes pthread_once to handle gracefully
init functions that exit by throwing exceptions. It has been
tested on ppc64, ppc64le, and x86_64 with no regressions.
During the discussion of the bug concerns were raised about
whether the use case of throwing exceptions from the
pthread_once init routine is intended to be supported either
by POSIX, or by GLIBC. After some research I believe that both
POSIX and GLIBC have, in fact, intended to support it, for at
least two reasons:
First, the POSIX Rationale states in section Thread Cancellation
Overview, under Thread Cancellation Cleanup Handlers, that:
it is an explicit goal of POSIX.1-2008 to be compatible with
existing exception facilities and languages having exceptions.
Second, as is evident from the comment above the pthread_once
declaration in GLIBC (quoted below), GLIBC too has intended
to support this use case since 2004 when the comment was
added (and the __THROW specification removed from the API):
...
The initialization functions might throw exception which
is why this function is not marked with __THROW. */
Martin