This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Async signal safe TLS accesses

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]