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

[Ian Lance Taylor <iant at google dot com>]

Roland McGrath <roland@hack.frob.com> writes:

>> Yes.  It would be much better if dlopen were changed to ensure that
>> every existing thread, and every newly created thread, picked up the
>> space required for the new TLS variables.
>
> Not really.  The former is not really feasible without perturbing the state
> of threads blocked in syscalls and such, since you would have to wake up
> every thread to run a special signal handler or something.  The latter is
> more doable, but it's questionable that it's really desireable.  A
> substantial part of the reason for the laziness of the whole thing is that
> not every thread will use every module's TLS space, so it's a waste to
> eagerly allocate all that space.  This is all part of the original design
> of TLS.  That design doesn't seem to really have contemplated people using
> GD TLS in signal handlers, but I have yet to be thoroughly convinced that
> the desire to do so is really anything but a sign of poor design of the
> modules in question at a higher level.

We are currently in an unpleasant situation where it is very easy and
natural to use TLS variables--you just refer to them by name--and using
them in a signal handler almost always works just fine.  Except that in
some highly specific but not completely implausible circumstances it
crashes incomprehensibly.  This is not a good thing, it's a lurking time
bomb.

I guess I'm not sure why you have to wake up a thread to add to its TLS
storage; can't you just stuff in the new memory?  Since it would happen
at dlopen time there is no way the thread could be referring to the new
memory yet.  But I haven't tried to fully grok the data structures
involved.  But, yet, this uses memory, perhaps unnecessarily.

Perhaps another approach would be to change __tls_get_addr to not use
malloc, but to use mmap as needed.  This of course assumes that mmap is
in fact async signal safe although it is not on the approved list.

Ian