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 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.

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.

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