apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Re: On to APR 2.0.0? Beyond 9x/ME
Date Mon, 16 Feb 2009 12:00:40 GMT
Nick Kew wrote:
> On Mon, 16 Feb 2009 08:06:11 +0100
> Mladen Turk <mturk@apache.org> wrote:
> 
>> One thing I've proposed (but was vetoed) was the actual
>> malloc/free programmable replacement within the allocator.
>> Now the thing to consider is to make the allocator public
>> allowing to implement what ever system memory allocation
>> there is (eg, heap or virtualmemory on win32, shm, etc)
>> instead just relying on standard allocator implementation
>> which (I presume that 8K granulation was more or less
>> empirically determined) is fixed.
> 
> Can you point to that discussion?

Here was the patch
http://svn.apache.org/viewvc?view=rev&revision=647394

Browse the archive for objections ;)

> Seems to me that if it
> can be done without performance penalties, then making the
> allocator into a public API should have potential to be the
> solution to make everyone happy.
> 

I'm not saying the the proposed API was perfect.
It only changed the internal allocator malloc/free.
The best thing would be to completely abstract the
allocator so that one can completely implement it's
own allocator.
The existing implementation would then change from:
mem = allocator_alloc(allocator, size)
to
mem = (*allocator->alloc)(allocator, size)

I don't think there will be any performance
penalties using that.


Regards
-- 
^(TM)

Mime
View raw message