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: Rich Felker <dalias at aerifal dot cx>
- 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 13:52:46 -0400
- 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>
On Fri, Sep 20, 2013 at 01:41:37PM -0400, Carlos O'Donell wrote:
> On 09/20/2013 10:25 AM, Ian Lance Taylor wrote:
> > Clearly it is technically infeasible to use some features from a
> > signal handler. I'm not going to waste time suggesting that it be
> > possible to call malloc from a signal handler. However, making it
> > safe to use __thread variables in a signal handler is not technically
> > infeasible. If we fail to support it, we're just being lazy.
>
> Good programmers are both lazy *and* dumb.
>
> Being lazy and dumb I don't want to maintain a complex TLS
> implementation, and being dumb means I can't.
>
> Therefore to overcome my lazy dumbness I suggest the following:
>
> * Discuss some alternative solutions to the problem at hand
> and why they were rejected.
Alternatives to which problem? Needing thread-local data in a signal
handling context? Formally, the only solution I see is using the
getpid() and &errno as keys into an on-disk file containing the
thread-local data. This is extraordinarily ugly.
> * Discuss the ISO C11 implications.
>
> ISO C11 wording in 7.14.1.1 p5:
The ISO C text on signal handlers is rather irrelevant. 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. 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),
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.
Rich