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: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Rich Felker <dalias at aerifal dot cx>, 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 22:08:23 +0000
- 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>
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.
I do think there is consensus for allowing TLS access in signal handlers.
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.
--
Joseph S. Myers
joseph@codesourcery.com