This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Async signal safe TLS accesses
- From: Rich Felker <dalias at aerifal dot cx>
- To: Carlos O'Donell <carlos at redhat dot com>
- 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, 2 Oct 2013 19:00:19 -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>
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