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

[Paul Pluzhnikov <ppluzhnikov at google dot com>]

On Wed, Jun 13, 2012 at 11:28 AM, Roland McGrath <roland@hack.frob.com> wrote:

> The obvious workaround is to make sure each thread has referred to a given
> __thread variable before a signal handler it runs might refer to it. ?That
> will ensure the dynamic linker has done all the allocation required
> beforehand.

When a library is dlopen()ed, it would be reasonable for it to force such
access from its initializer.

Unfortunately, that would require iterating over all pre-existing threads
and calling some routine in each thread, which is near impossible (as far
as I can tell). If in fact there is an existing mechanism to do this,
I'll be happy to use it.

> Or else, the DSO can use __attribute__ ((tls_model ("initial-exec"))) for
> the variable it wants to use in a signal handler.

That doesn't generally work: as far as I can tell, a single "initial-exec"
TLS variable in a DSO makes *all* TLS variables in the DSO use that model.

If there are a couple, very quickly you end up with a DSO that fails to
dlopen with "cannot load any more object with static TLS" due to DTV_SURPLUS
exhaustion.

> Only if those are really not practical in a real-world example should we
> consider adding bizarre new features for this corner case.

That's one question I have: how much of a corner case is this really?

At Google we are hitting that corner case with all of our Java programs. I'd
be somewhat surprised if it turns out that nobody else needs this feature.

Thanks,
-- 
Paul Pluzhnikov