apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Re: svn commit: r647394 - in /apr/apr/trunk: CHANGES include/apr_pools.h memory/unix/apr_pools.c
Date Thu, 17 Apr 2008 04:32:04 GMT
Joe Orton wrote:
> Can you explain some of those other things might be?  There are multiple 
> ways you can hook into a profiling toolkit without requiring source code 
> changes:
> 1) compile-time hacks to #define malloc
> 2) at link-time link against some library which provides malloc etc 
> before libc
> 3) at load-time LD_PRELOAD a library which overrides libc malloc etc

In multiplatform environment only the 1) is valid
option. However it lacks API for profiling, so basically
you cannot hook into apr from your application unless
you recompile your application as well and like you
said do some hacks.

Further more, profiling is just one of the use cases.
Other is application provided memory allocation not
known at the apr compile time. I reverted the patch
because it was incomplete. It should address both
internal usage of malloc, per allocator memory
callbacks (similar how malloc calls sbrk) and statistical
data if APR_POOL_PROFILE was defined in apr compile time.


View raw message