diff options
author | Martin Sebor <msebor@redhat.com> | 2015-07-01 14:05:27 -0600 |
---|---|---|
committer | Martin Sebor <msebor@redhat.com> | 2015-07-01 14:05:27 -0600 |
commit | ed225df3ad9cbac3c22ec3f0fbbed1f9c61d1c54 (patch) | |
tree | 175abf6476b8924e619c559993324efdb855e392 /manual/install-plain.texi | |
parent | 9081b7bcb11e74cd2d4363663ccd1bb641392719 (diff) | |
download | glibc-ed225df3ad9cbac3c22ec3f0fbbed1f9c61d1c54.tar.gz glibc-ed225df3ad9cbac3c22ec3f0fbbed1f9c61d1c54.tar.xz glibc-ed225df3ad9cbac3c22ec3f0fbbed1f9c61d1c54.zip |
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++. This patch changes pthread_once to handle gracefully init functions that exit by throwing exceptions. It was successfully tested on ppc64, ppc64le, and x86_64. [BZ #18435] * nptl/Makefile: Add tst-once5.cc. * nptl/pthreadP.h (pthread_cleanup_push, pthread_cleanup_pop): Remove macro redefinitions. * nptl/tst-once5.cc: New test.
Diffstat (limited to 'manual/install-plain.texi')
0 files changed, 0 insertions, 0 deletions