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 Tue, 15 Apr 2008 04:48:23 GMT
Joe Orton wrote:
 > On Sat, Apr 12, 2008 at 08:42:59AM -0000, Mladen Turk wrote:
 >> Author: mturk
 >> Date: Sat Apr 12 01:42:51 2008
 >> New Revision: 647394
 >> URL: http://svn.apache.org/viewvc?rev=647394&view=rev
 >> Log:
 >> Introduce apr_pool_sys_allocator_set
 > Why can't you just use a custom allocator for whatever the problem is 
here?  That's what the allocator abstraction is *for*, right?  Adding 
yet another abstraction above the allocator seems really wrong; 
especially since it introduces a bunch of global state and *everybody* 
suffers the overhead of the additional function calls and conditionals.

How can I use custom allocator from outside apr?
The allocator is private, so cannot be customized from application.
It relies on malloc/free, and the point of patch is to abstract those
calls. Patch itself only sets the function pointer, and since its
warper is inline function the proper compiler should make no
overhead except one JNZ instruction.

The point is that apr internally uses system allocator and
we presume this should be malloc/free. Any other mechanism
is ruled out by that presumption. malloc/free might not be the
most effective way to allocate the memory from the system in
all use cases. It also doesn't allow things like profiling
and all other sort of things the application might have.
Once you create an allocator you don't have a track what's
going on beneath. You don't know how apr internally allocates
the memory from the system. Those callbacks if set are the

However if you really think this is an too high overhead
we might add compile time switch (APR_POOL_PROFILE) that
if not set will skip out this single compare instruction.


View raw message