On Tue, Apr 15, 2008 at 06:48:23AM +0200, Mladen Turk wrote: > 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.
Good point. > 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. 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 Regards, joe
