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: Andrew Hunter <ahh at google 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>, Alexandre Oliva <aoliva at redhat dot com>
- Date: Tue, 24 Sep 2013 14:40:13 -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> <CAKOQZ8ze1zKdQRsMsmBCqnJr361Gvv8mYjLjGgzYwWJEKUY+7w at mail dot gmail dot com> <523CB72A dot 7040507 at redhat dot com> <CAKOQZ8yq6gnWig3Wg4YF0qOYTJbevEExG0Sm9K4ofsSO+PWq1A at mail dot gmail dot com> <5241F2CF dot 9020004 at redhat dot com> <CADroS=712-dg+bwR-HY9mYNFPSU=oZekwUJaA8dRqs1-o=-qcQ at mail dot gmail dot com> <5242036A dot 8020004 at redhat dot com>
On Tue, Sep 24, 2013 at 2:26 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 09/24/2013 04:21 PM, Andrew Hunter wrote:
>> On Tue, Sep 24, 2013 at 1:15 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>>> Thanks. I still think we need to look at interrupted initialization
>>> as another possible problem.
>>
>> My patch addresses that (the simplest way possible--masking out signals.)
>
> Thanks I saw that. I need to update the design document to cover exactly
> what the patch is doing in that case.
>
> It's certainly a future enhancement to use an atomic operation with a
> retry, but I don't know if the complexity is worth it. I also don't know
> if the blocked signals show up at all as increased latency in responding
> to other signals. Do you have any figures on that?
>
I don't, sorry. My expectation is that since this cost will be paid
precisely once per thread per dlopened object with TLS (it's entirely
off the fast path) that it's unlikely to be a noticable performance
problem.
FYI, on my recent-ish Intel system, a mask/unmask pair is under 350
nanoseconds. The block times aren't likely to be much longer; the
most expensive thing done there is (at most) two small mmaps (if we
don't override with a better malloc.) mmap'ing a page and populating
it costs <2 microseconds on my system. I would be very surprised,
other than in very large TLS arrays or very strange circumstances, if
tls_get_addr() took more than a millisecond on CPU.