Re: [PATCH] Async signal safe TLS accesses

["Carlos O'Donell" <carlos at redhat dot com>]

On 10/02/2013 07:00 PM, Rich Felker wrote:
> 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...

No, no public API should have __-prefixed names.

Thanks, I understand your point and agree.

You'll see the result of my review which is to say "Use __foo for
the signal-safe allocation functions."

The public API discussions will have to happen after this patch goes in.

Cheers,
Carlos.