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: "Carlos O'Donell" <carlos at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery 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, 02 Oct 2013 18:59:48 -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> <Pine dot LNX dot 4 dot 64 dot 1310022203420 dot 22120 at digraph dot polyomino dot org dot uk>
On 10/02/2013 06:08 PM, Joseph S. Myers wrote:
> 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.
That's OK. We can have that discussion after the discussion about TLS
accesses in signal handlers which is related but orthogonal.
> I do think there is consensus for allowing TLS access in signal handlers.
Agreed.
> 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.
You are right that we haven't really reached a consensus there.
Won't such an decision undo the lazy allocation benefits?
Will this not increase the amount of memory used by each thread after a
dlopen even if the thread in question never uses TLS from the loaded library?
Am I understanding your point correctly?
Cheers,
Carlos.