This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Async signal safe TLS accesses
- From: Rich Felker <dalias at aerifal dot cx>
- To: Andrew Hunter <ahh at google dot com>
- Cc: Ian Lance Taylor <iant at google dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Paul Pluzhnikov <ppluzhnikov at google dot com>
- Date: Wed, 2 Oct 2013 19:29:25 -0400
- Subject: Re: [PATCH] Async signal safe TLS accesses
- Authentication-results: sourceware.org; auth=none
- References: <20130924025738 dot GK20515 at brightrain dot aerifal dot cx> <524C3467 dot 2030503 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1310022203420 dot 22120 at digraph dot polyomino dot org dot uk> <CAKOQZ8wN0ecYROnxNT5edV5yxr5jiAuoLVg4ErO9DZq3SYj4HQ at mail dot gmail dot com> <20131002223612 dot GA20515 at brightrain dot aerifal dot cx> <CADroS=6qkwBbdq8M0Lq7_k0p3oB+asnhcPnEyrrzu65MUAd0rQ at mail dot gmail dot com> <20131002225311 dot GB20515 at brightrain dot aerifal dot cx> <CADroS=4E1f2UOJa5_QCHr+9-P1ksXmrKbyXPVrWmEgL0o=diYg at mail dot gmail dot com> <20131002231443 dot GE20515 at brightrain dot aerifal dot cx> <CADroS=7=EW302m+cZ6xx74PU9Pwc8JM-=UHmyNFx0=Pcv7zMbw at mail dot gmail dot com>
On Wed, Oct 02, 2013 at 04:17:04PM -0700, Andrew Hunter wrote:
> On Wed, Oct 2, 2013 at 4:14 PM, Rich Felker <dalias@aerifal.cx> wrote:
> > On Wed, Oct 02, 2013 at 04:03:01PM -0700, Andrew Hunter wrote:
> >> On Wed, Oct 2, 2013 at 3:53 PM, Rich Felker <dalias@aerifal.cx> wrote:
> >> > Since when does dlopen support initial-exec? I am not aware of any
> >> > such support, and it certainly can't work in general since the needed
> >> > address range might not even be available.
> >> >
> >>
> >> It certainly does since at least 2.15; I haven't searched the history
> >> for its initial creation. It, indeed, can fail; by default glibc
> >> appears to allocate 1600 bytes/thread for "surplus" initial-exec TLS
> >> (that is, that which is found in dlopen'd objects); dlopen will fail
> >> if that is exhausted.
> >
> > In that case, our current discussion does not apply. TLS allocated
> > into the "surplus" initial TLS zone would be handled the same as it is
> > now, not via anything new under present discussion.
>
> Except that this zone has to be initialized in all threads by
> dlopen--it _cannot_ be done lazily on first access as you suggest for
> dynamic accesses.
Presumably it's already being done then, in some hideous way...
> I agree that my patch doesn't change this meaningfully, I'm just
> saying that this feature means we absolutely must iterate and update
> living threads, something you wanted to avoid.
My point was that no new code would have to do this. Whether existing
hideous code is doing so it a completely separate matter.
Rich