Re: svn commit: r761662 - /apr/apr/trunk/memory/unix/apr_pools.c

[Mladen Turk <mt...@apache.org>]

rpluem@apache.org wrote:
> Author: rpluem
> Date: Fri Apr  3 13:13:26 2009
> New Revision: 761662
> 
> URL: http://svn.apache.org/viewvc?rev=761662&view=rev
> Log:
> * Correctly setup size field for the final_blocks field.
> 
> Modified:
>     apr/apr/trunk/memory/unix/apr_pools.c
> 
> Modified: apr/apr/trunk/memory/unix/apr_pools.c
> URL: http://svn.apache.org/viewvc/apr/apr/trunk/memory/unix/apr_pools.c?rev=761662&r1=761661&r2=761662&view=diff
> ==============================================================================
> --- apr/apr/trunk/memory/unix/apr_pools.c (original)
> +++ apr/apr/trunk/memory/unix/apr_pools.c Fri Apr  3 13:13:26 2009
> @@ -825,6 +825,7 @@
>          pool->blocks = &pool->final_block;
>          pool->blocks->offset = 0;
>          pool->blocks->next = NULL;
> +        pool->blocks->size = BLOCK_LIST_ENTRIES_MIN;

Right.
However the entire final_block is complete waste of
space if the pool wasn't created explicitly with it's own
allocator using apr_pool_create_ex.
And the sole purpose of it is to allocate the mutex.

Since mutex creation calls few apr_palloc an
additional malloc for making the block_lists dynamic
would make no difference.

Regards
-- 
^(TM)