This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] malloc: add locking to thread cache
- From: Jörn Engel <joern at purestorage dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: "GNU C. Library" <libc-alpha at sourceware dot org>, Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, nd at arm dot com
- Date: Tue, 26 Jan 2016 09:40:51 -0800
- Subject: Re: [PATCH] malloc: add locking to thread cache
- Authentication-results: sourceware.org; auth=none
- References: <1453767942-19369-1-git-send-email-joern at purestorage dot com> <1453767942-19369-52-git-send-email-joern at purestorage dot com> <56A76A49 dot 8010804 at arm dot com>
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.
Jörn
--
Functionality is an asset, but code is a liability.
--Ted Dziuba