Async-signal-safe access to __thread variables from dlopen()ed libraries?

[Carlos O'Donell]

On 09/20/2013 10:23 AM, Alexandre Oliva wrote:
> On Sep 18, 2013, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:
> 
>> - introduces async-signal-safe mmap-based allocator into elf/dl-misc.c, and
>> - updates the rest of the loader to use this allocator when getting space
>>   for non-static TLS.
> 
> Why not make malloc AS-safe instead?  I've reviewed it, and having
> multiple arenas seems to make it not too hard to use an alternate arena
> if the primary arena for a thread happens to be already locked.  It's
> only if we have to create a new arena that we might get in trouble, but
> then, worst case, malloc itself can always fallback to mmapped
> allocation.
> 
> Wouldn't that be a more advantageous path to take?
 
Yes and no.

It would be advantageous in that having access to malloc from a signal
handler is another useful function you can use.

The disadvantage is that you now have to maintain malloc AS-safe
forever and auditing that much code is difficult from a maintenance
perspective. In addition to that it's a non-portable use of malloc
that impacts portability.

It would be easier to audit a smaller and simpler allocator that
can be used exclusively for TLS allocations from within the
dynamic loader.

Therefore I would not attempt to pursue making malloc AS-safe
as it may inhibit optimizations we may want to make in the future.

Cheers,
Carlos.