[PATCH] Async signal safe TLS accesses

[Rich Felker]

On Wed, Oct 02, 2013 at 06:55:37PM -0400, 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.
> >>
> >> Thus I don't think we need to worry about this yet, but you can
> >> start talking about it and discussion what it should be named.
> >>
> >> What do you suggest?
> > 
> > I think the public API is unrelated. For better or worse, the public
> > API cannot be allowed to override the internal signal-safe functions
> > used by TLS, because the latter are in the namespace reserved for the
> > implementation whereas the former should be in the application
> > namespace.
> 
> Sorry, I don't follow.
> 
> Are you suggesting two things here?
> 
> (a) Do not allow user code to override internal signal-safe allocation
>     functions.
> 
> and
> 
> (b) Provide a distinct signal-safe allocation API that users can use
>     and override, but which is not used by the implementation internally.
> 
> Is that what you mean?

What I mean is that the namespace for the internal signal-safe
allocation used by TLS and the namespace for a new public signal-safe
allocation API are disjoint. I don't have any particular position on
whether it should be allowed to override the internal one (question
(a) above) or whether a public API should be provided (question (b));
my intent was just to highlight that the two have to be separate,
unless you want to propose making a public API with __-prefixed
functions...

Rich