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: OndÅej BÃlka <neleai at seznam dot cz>, Alexandre Oliva <aoliva at redhat dot com>, 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: Fri, 29 Nov 2013 10:05:31 -0500
- Subject: Re: [PATCH] Async signal safe TLS accesses
- Authentication-results: sourceware.org; auth=none
- References: <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> <20131129035506 dot GA20469 at domone dot podge> <20131129040117 dot GZ24286 at brightrain dot aerifal dot cx> <5298175B dot 8090604 at redhat dot com>
On Thu, Nov 28, 2013 at 11:26:03PM -0500, Carlos O'Donell wrote:
> On 11/28/2013 11:01 PM, Rich Felker wrote:
> > On Fri, Nov 29, 2013 at 04:55:48AM +0100, OndÅej BÃlka wrote:
> >> A proper solution would be make generic malloc async-signal safe. It is
> >> question of what is acceptable overhead. I can make a wrapper over any
> >> allocator that does that at cost of two tls access. You would pay a mmap
> >> overhead only when you are in signal where we do not care about
> >> effectivity.
> >
> > Not a solution as long as glibc officially supports applications
> > replacing malloc.
>
> The loader could access the implementation's malloc via GLIBC_PRIVATE
> symbols.
Running the glibc malloc while a third-party malloc is also in use is
not going to work. The third-party malloc can (and probably does)
assume it has exclusive rights to the brk.
Rich