[PATCH] Async signal safe TLS accesses

[Carlos O'Donell]

On 10/02/2013 06:08 PM, Joseph S. Myers wrote:
> On Wed, 2 Oct 2013, Carlos O'Donell wrote:
> 
>> I'm pretty sure that we have consensus that the public API will
>> need to be done as a follow-on patch to the original support for
>> TLS in signal handlers.
> 
> I don't think there's a consensus that there should be such a public API 
> for signal-safe allocation at all.

That's OK. We can have that discussion after the discussion about TLS
accesses in signal handlers which is related but orthogonal.

> I do think there is consensus for allowing TLS access in signal handlers.  

Agreed.

> I'd like there to be consensus for TLS accesses never failing (i.e. all 
> dynamic allocation being done at thread creation time or dlopen time, when 
> it's possible to return an error status, and initial accesses doing no 
> more than associating a variable with memory from a pool where a 
> sufficient amount of memory is guaranteed to have been allocated at one of 
> those times), but while I don't think anyone has objected to that, I'm not 
> sure enough people have actually thought about it.

You are right that we haven't really reached a consensus there.

Won't such an decision undo the lazy allocation benefits?

Will this not increase the amount of memory used by each thread after a 
dlopen even if the thread in question never uses TLS from the loaded library?

Am I understanding your point correctly?

Cheers,
Carlos.