This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 10/19/2017 01:04 PM, Szabolcs Nagy wrote:
On 19/10/17 11:37, Florian Weimer wrote:On 10/19/2017 11:44 AM, Szabolcs Nagy wrote:On 17/10/17 23:19, Florian Weimer wrote:Global-dynamic currently has lazy allocation for each thread, so a library constructor is not good enough to ensure initialization. We probably want to fix this, but major language standards say that TLS access from signal handlers is undefined, so it's not even a real bug.the relevant standard for a libc implementation is iso c which has 7.14.1.1p5 "If the signal occurs other than as the result of calling the abort or raise function, the behavior is undefined if the signal handler refers to any object with static or thread storage duration that is not a lock-free atomic object other than by assigning a value to an object declared as volatile sig_atomic_t, or the signal handler calls any function in the standard library other than the abort function, the _Exit function, the quick_exit function, or the signal function with the first argument equal to the signal number corresponding to the signal that caused the invocation of the handler." i.e. lock-free atomic and volatile sig_atomic_t tls access should work.For us, it depends on the TLS model. Async-signal-safe TLS access is considered unimplementable in general,musl implements it: you just have to allocate tls for all dsos and all threads in dlopen and pthread_create. (if unbounded dlopen/dlclose calls are supported then it's a bit trickier since dtv slots need to be reused then, but should be possible in principle)
We have received guidance that this is not desirable for all TLS usage scenarios. Some applications might not want to allocate backing storage for the full set of TLS variables for those threads which do not need all of them.
But the entire world is not Linux.
which is why C++ makes it undefined: “ \pnum \indextext{signal-safe!evaluation|see{evaluation, signal-safe}}% An evaluation is \defnx{signal-safe}{evaluation!signal-safe} unless it includes one of the following: \begin{itemize} […] \item an access to an object with thread storage duration; ”that's new text in c++17 (and yet another incompatibility with c).
In general, the C++ standard adheres much more to implementation experience than the C standard. This incompatibility is probably a defect in the C standard.
Thanks, Florian
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |