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 /sysdeps/generic/eloop-threshold.h | |
parent | 9081b7bcb11e74cd2d4363663ccd1bb641392719 (diff) | |
download | glibc-ed225df3ad9cbac3c22ec3f0fbbed1f9c61d1c54.tar glibc-ed225df3ad9cbac3c22ec3f0fbbed1f9c61d1c54.tar.gz glibc-ed225df3ad9cbac3c22ec3f0fbbed1f9c61d1c54.tar.bz2 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 'sysdeps/generic/eloop-threshold.h')
0 files changed, 0 insertions, 0 deletions