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] malloc: add locking to thread cache

On Tue, Jan 26, 2016 at 12:44:57PM +0000, Szabolcs Nagy wrote:
> On 26/01/16 00:25, Joern Engel wrote:
> > With signals we can reenter the thread-cache.  Protect against that with
> > a lock.  Will almost never happen in practice, it took the company five
> > years to reproduce a similar race in the existing malloc.  But easy to
> > trigger with a targeted test.
> why do you try to make malloc as-safe?

Why would I not?  I find it easier to make malloc signal-safe than to
find an alternative fix for the signal handler of a single application.
If nothing else, the cost of entering the signal handler a million times
is much lower for a malloc stresstest than an application.

> isn't it better to fix malloc usage in signal handlers?

If your goal is portability across many different malloc libraries, I
would agree.  If your goal is to fix deadlocks in applications, changing
malloc is a more economical use of your time.


Functionality is an asset, but code is a liability.
--Ted Dziuba

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