This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Async signal safe TLS accesses

On Wed, Oct 02, 2013 at 04:17:04PM -0700, Andrew Hunter wrote:
> On Wed, Oct 2, 2013 at 4:14 PM, Rich Felker <> 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 <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]