なんか、glibc 2.14のリリースノートでmalloc hookはthread unsafeだから
そのうち消すよーとか言ってますな
http://sourceware.org/ml/libc-alpha/2011-05/msg00103.html
libc-alphaで最近文句つけてる人がいた
そのうち消すよーとか言ってますな
http://sourceware.org/ml/libc-alpha/2011-05/msg00103.html
* The malloc hook implementation is marked deprecated and will be removed
from the default implementation in the next version. The design never
worked ever since the introduction of threads. Even programs which do
not create threads themselves can use multiple threads created internally.
libc-alphaで最近文句つけてる人がいた
From: Emery Berger
Date: Tue, 26 Jul 2011 16:41:14 +0200
Message-ID:
Subject: glibc malloc hook deprecation considered harmful
To: libc-alpha@sourceware.org
Hi all,
I see that malloc hooks have been deprecated and are scheduled for removal:
http://sourceware.org/ml/libc-alpha/2011-05/msg00103.html
Unless there is a better replacement in the offing, I would like to
argue that they remain.
The claim has been made that these hooks do not work in the presence
of threads. I agree that it is unsafe for a program to change these on
the fly.
However, as far as I am aware, they are the only safe / reliable means
of intercepting malloc for an entire program, at least on Linux
platforms.
Invoking them at startup (via init_hook) works well. Hoard relies on
it (www.hoard.org), and it works just fine for massively multithreaded
programs used in a large variety of industrial settings (British
Telecom, Credit Suisse, Reuters, to cite just a few). In addition to
Hoard and DieHard (www.diehard-software.org), I am sure there are
other allocators that rely on malloc hooks.
Without malloc hooks, there is no way to be certain that all
allocation functions have been intercepted. Authors of malloc
implementations otherwise have to play catch-up with every new version
of glibc to (hopefully) intercept all functions that accessed malloc
internally (via __libc_malloc or somesuch). The hooks work well --
please keep them or provide a suitable replacement.
Best,
-- Emery Berger