Re: [PR19826] fix non-LE TLS in static programs

[Florian Weimer <fweimer at redhat dot com>]

On 12/06/2016 10:30 AM, Alexandre Oliva wrote:

> *nod*.  I think we could make malloc AS-Safe by having an alternate
> arena to fallback to, if the preferred arena is already locked, and if
> we realize we have to fallback to the alternate arena, we block signals
> before locking it and unblock them once the allocation is done.  This
> would probably be better than using an alternate allocator for the DTV
> and for Static TLS and whatnot.

We need a separate allocator for thread-local data to get predictable 
performance, especially in NUMA environments.  Otherwise, application 
could get unlucky and put TLS data structures on the same page as 
application data used by a completely different thread, and performance 
will be horrible.

> > It's not just a problem for asynchronous signals, we do not have a way
> > to report allocation failures, either.
>
> Yeah, that's an essential consequence of deferred allocation of dynamic
> TLS blocks and of per-thread DTV resizing.  We could avoid part of it by
> always allocating TLS blocks statically, with some additional
> synchronization at dlopen, but dealing with the DTV could be a lot more
> interesting.

But we know its size at dlopen time, right?  So we could perform the 
allocation then and just defer installing it.

Thanks,
Florian