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: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Paul Pluzhnikov <ppluzhnikov at google dot com>, Andrew Hunter <ahh at google dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Mon, 02 Dec 2013 16:51:41 -0500
- Subject: Re: [PATCH] Async signal safe TLS accesses
- Authentication-results: sourceware.org; auth=none
- References: <1380830518-16721-1-git-send-email-ahh at google dot com> <1382477766-15770-1-git-send-email-ahh at google dot com> <Pine dot LNX dot 4 dot 64 dot 1310222145490 dot 13258 at digraph dot polyomino dot org dot uk> <CALoOobMsO6X86JFD4J7F-EL-J+xOTEOVbzH=6mwrvfCnFvw57Q at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1311052233090 dot 30260 at digraph dot polyomino dot org dot uk> <CALoOobM70-mix+=1zuDnSoK7SRqQChbL=03xBkUcFf1fyS1Mjw at mail dot gmail dot com> <CALoOobP7kdpZCZA0a7MZWCtONu81fW4H_qAWOEfpfvzxJgG_=Q at mail dot gmail dot com> <CALoOobP6rTDosadvLKhHY+deDsU-FtvyO8QX_Y4dZy716e2ATQ at mail dot gmail dot com> <CALoOobOCT-inwMZkzEr+JYT4c8qwpN-EGMPFu_kHQTpc2icj0g at mail dot gmail dot com> <CALoOobPHo7+jG0nfiZp9afC2rArLUMRYZEag21W+78UBTZF=CQ at mail dot gmail dot com> <orvbzckoif dot fsf at livre dot home> <52981C48 dot 2080609 at redhat dot com> <orppphk8e2 dot fsf at livre dot home>
On 11/30/2013 02:16 PM, Alexandre Oliva wrote:
> On Nov 29, 2013, "Carlos O'Donell" <carlos@redhat.com> wrote:
>
>> The one page is wasted for the sake of simplicity of implementation
>> and maintenance. The more complex this code becomes the harder it
>> is to review for AS-safety.
>
> While I agree with the latter sentence in principle, I think this goes
> too far in complexity-avoidance, and I claim we already have a
> provably-safe allocation strategy that reuses malloc, does not incur
> such waste, and is very performant.
>
> I've already alluded to it in my earlier email: using the existing
> malloc implementation with an arena that is only ever locked when
> signals are disabled.
>
> Why is this AS-Safe?
[snip detailed AS-Safe reasoning for malloc]
Your reasoning seems quite sound, but for now, given that Google has
already done the work, and there is no public API discussion, I'm
going to leave this discussion until further down the road when we
go back to address having a public AS-Safe allocation API that users
can use. In that contact I think we'll need to have a discussion
about malloc-based vs. something else.
Cheers,
Carlos.