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: Torvald Riegel <triegel at redhat dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, 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: Wed, 02 Oct 2013 11:16:44 +0200
- Subject: Re: Async-signal-safe access to __thread variables from dlopen()ed libraries?
- Authentication-results: sourceware.org; auth=none
- References: <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> <20130920175246 dot GE20515 at brightrain dot aerifal dot cx>
On Fri, 2013-09-20 at 13:52 -0400, Rich Felker wrote:
> On Fri, Sep 20, 2013 at 01:41:37PM -0400, Carlos O'Donell wrote:
> > * Discuss the ISO C11 implications.
> >
> > ISO C11 wording in 7.14.1.1 p5:
>
> The ISO C text on signal handlers is rather irrelevant.
While you can certainly target POSIX and treat what C defines as
secondary regarding signal handling, I don't agree that C's definitions
are irrelevant: If you want portable C11 code, you will rely on what ISO
C specifies.
Now, that isn't a reason to not provide stronger guarantees than ISO C;
I don't see how ISO C would require TLS to *become* atomic, it just
doesn't want to give guarantees for any non-atomic variables.
> In plain C,
> there is nothing useful you can do from a signal handler whatsoever,
> nor is there anything useful that can cause a signal.
By "plain C" you mean pre-C11?
> POSIX specifies
> a lot more you can do with signal handlers (it defines many of the
> undefined aspects), but the current POSIX spec actually has lots of
> bugs; see:
>
> http://austingroupbugs.net/view.php?id=728
>
> > Will our TLS variables become lock-free atomic objects?
>
> I don't see how this question is related at all. Atomic in the C11
> sense has to do with synchronization between processors, not signals.
> The memory model for access to objects from signal handlers should not
> define the behavior when the signal handler accesses an object whose
> modification the signal handler interrupted, except for objects of
> type sig_atomic_t or character types (I added the latter because the
> C11 memory model already requires byte-granularity write operations),
You mean plain character types like a non-atomic char? I doubt that
trying to give guarantees for those is right because it would prevent
optimizations.
> but otherwise (as long as the signal handler is sequenced to avoid
> such access, e.g. using signal masks) access to arbitrary objects from
> signal handlers should be unrestricted.
At least in ISO C++ there is an open issue how to specify the memory
model bits related to signal handling:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3633.html
There has also been discussion about whether access to TLS from signal
handlers should actually be allowed at all, because implementations of
TLS access might use non-recursive locks (or other potentially
non-reentrancy-safe pieces of code) internally.