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: Rich Felker <dalias at aerifal dot cx>
- 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:20:40 -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> <20131129150530 dot GB24286 at brightrain dot aerifal dot cx>
On 11/29/2013 10:05 AM, Rich Felker wrote:
> 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.
I agree that we'd have to address this particular detail if we went
with such a solution.
I'm not in favour of wrapping or reusing malloc in any way for a
signal-safe allocator. I want to keep the two allocators distinct
and with a simple set of goals and design criteria.
Cheers,
Carlos.