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

[Andrew Hunter]

On Tue, Sep 24, 2013 at 2:26 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 09/24/2013 04:21 PM, Andrew Hunter wrote:
>> On Tue, Sep 24, 2013 at 1:15 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>>> Thanks. I still think we need to look at interrupted initialization
>>> as another possible problem.
>>
>> My patch addresses that (the simplest way possible--masking out signals.)
>
> Thanks I saw that. I need to update the design document to cover exactly
> what the patch is doing in that case.
>
> It's certainly a future enhancement to use an atomic operation with a
> retry, but I don't know if the complexity is worth it. I also don't know
> if the blocked signals show up at all as increased latency in responding
> to other signals. Do you have any figures on that?
>

I don't, sorry.  My expectation is that since this cost will be paid
precisely once per thread per dlopened object with TLS (it's entirely
off the fast path) that it's unlikely to be a noticable performance
problem.

FYI, on my recent-ish Intel system, a mask/unmask pair is under 350
nanoseconds.  The block times aren't likely to be much longer; the
most expensive thing done there is (at most) two small mmaps (if we
don't override with a better malloc.)  mmap'ing a page and populating
it costs <2 microseconds on my system.  I would be very surprised,
other than in very large TLS arrays or very strange circumstances, if
tls_get_addr() took more than a millisecond on CPU.