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: Ian Lance Taylor <iant at google dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: 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 10:56:56 -0700
- 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, Sep 20, 2013 at 10:41 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>
> * Discuss the ISO C11 implications.
As you can see by reading them, the ISO C11 rules for signal handlers
are completely useless for real programs. That is why POSIX adds many
additional guarantees to what can be done in a signal handler.
> Will our TLS variables become lock-free atomic objects?
Not in general, no. But should we reject the ability to use atomic
intrinsics on __thread variables?
> * Provide changes to the manual to explain that accessing
> thread local storage is now async-signal safe and
> will be going forward.
To which manual are you referring?
> * Consider providing some way to assure that old programs
> using TLS in a signal handler fail safe. If it can't
> be assured, explain why not.
If we could do only that, I would not ask for anything else.
> * Similarly provide symbol versioning to prevent a new
> program from being run on an old glibc that doesn't
> provide AS-safe TLS vars.
Seems really unnecessary to me.
> * Work with the community to ensure consensus around an
> acceptable solution.
To be clear, Google already has a patch, as Paul mentioned in the
message that restarted this thread. And frankly I thought this idea
was a slam dunk if it could be implemented, and I'm surprised to see
so much resistance. At this point I have to say that the community
does not seem interested, so my inclination would be to skip it and
just do something that works internally. That is disappointing but it
is quite possible that I am missing something about this issue.
Ian