This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Async signal safe TLS accesses
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: Andrew Hunter <ahh at google dot com>, libc-alpha at sourceware dot org, iant at google dot com, ppluzhnikov at google dot com
- Date: Wed, 02 Oct 2013 19:02:11 -0400
- Subject: Re: [PATCH] Async signal safe TLS accesses
- Authentication-results: sourceware.org; auth=none
- References: <523F2ED8 dot 8090909 at redhat dot com> <1379977289-21260-1-git-send-email-ahh at google dot com> <20130924025738 dot GK20515 at brightrain dot aerifal dot cx> <524C3467 dot 2030503 at redhat dot com> <20131002205244 dot GU20515 at brightrain dot aerifal dot cx> <524CA469 dot 5090606 at redhat dot com> <20131002230019 dot GC20515 at brightrain dot aerifal dot cx>
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
>> Sorry, I don't follow.
>> Are you suggesting two things here?
>> (a) Do not allow user code to override internal signal-safe allocation
>> (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
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.