https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
Rich Felker <bugdal at aerifal dot cx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bugdal at aerifal dot cx
--- Comment #9 from Rich Felker <bugdal at aerifal dot cx> ---
This is not portable usage of pthread_once. The longjmp based version is
clearly wrong, per the resolution of http://austingroupbugs.net/view.php?id=863
and while POSIX has nothing to say about C++, the lack of any text forbidding
the analogous C++ construct does not make a requirement to support it.
FYI, this type of usage is not supported, and impossible to support, in musl's
implementation of pthread_once (which does not interact with
exceptions/unwinding, only with thread cancellation).
There's a slim chance the C11 call_once function could be used, but I think the
way it's specified also requires this kind of deadlock if you leave the init
routine via any means but returning, and it's not widely supported yet anyway.
I think the right solution is to use atomics directly to implement
std::call_once and only fallback to pthread sync primitives in the contended
case. As long as you don't pass arbitrary C++ callback functions provided by
the caller to pthread_once, it should be safe to use any pthread functions.
