This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Async-signal-safe access to __thread variables from dlopen()ed libraries?
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Ian Lance Taylor <iant at google dot com>, Paul Pluzhnikov <ppluzhnikov at google dot com>, Roland McGrath <roland at hack dot frob dot com>, Richard Henderson <rth at twiddle dot net>, GNU C Library <libc-alpha at sourceware dot org>, Andrew Hunter <ahh at google dot com>, Alexandre Oliva <aoliva at redhat dot com>
- Date: Fri, 20 Sep 2013 20:16:05 +0000
- Subject: Re: Async-signal-safe access to __thread variables from dlopen()ed libraries?
- Authentication-results: sourceware.org; auth=none
- References: <20120612193224 dot 8E43619060E at elbrus2 dot mtv dot corp dot google dot com> <4FD8D974 dot 7090903 at twiddle dot net> <20120613182826 dot 0CFAB2C0A3 at topped-with-meat dot com> <CALoOobMtXCw+oe7ZL0=my8YH5st8b1==CasS8i07z6G9DfaX-w at mail dot gmail dot com> <20120613210444 dot 659732C095 at topped-with-meat dot com> <mcr4nqebzok dot fsf at dhcp-172-18-216-180 dot mtv dot corp dot google dot com> <20120614002931 dot ABB762C08B at topped-with-meat dot com> <mcr1uliaeep dot fsf at dhcp-172-18-216-180 dot mtv dot corp dot google dot com> <CALoOobPJ7G7ciRfc2JwzHjsDTg4-_h-SXqeU1zR4WEzoyQhyNg at mail dot gmail dot com> <523BD470 dot 6090203 at redhat dot com> <CAKOQZ8y85QBkd97cEEmP-4OgE2KizCqknrVR_n44pwBGMs5uAw at mail dot gmail dot com> <523C88D1 dot 6090304 at redhat dot com>
On Fri, 20 Sep 2013, Carlos O'Donell wrote:
> Will our TLS variables become lock-free atomic objects?
If they are declared with an _Atomic type for which the corresponding
ATOMIC_*_LOCK_FREE is defined, they should be.
> * Similarly provide symbol versioning to prevent a new
> program from being run on an old glibc that doesn't
> provide AS-safe TLS vars.
Not needed.
However, since there are two separate but related problems (AS-safe access
to TLS variables, and ensuring allocation failure is reliably indicated by
pthread_create or dlopen failure, rather than happening on access to a TLS
variable when there is no good way to return a failure status),
considering how the design for fixing one problem relates to the other
problem (e.g. whether it introduces new code that would need to be removed
again when fixing the other problem) is certainly relevant.
I think both problems are appropriate to fix (and should have separate
bugs opened for them in Bugzilla, if not already open).
--
Joseph S. Myers
joseph@codesourcery.com