apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: Pools rewrite [4]
Date Wed, 12 Dec 2001 12:42:21 GMT
> From: Brian Pane [mailto:bpane@pacbell.net]
> Sent: 11 December 2001 18:21
> Sander Striker wrote:
>>> From: Brian Pane [ mailto:bpane@pacbell.net]
>>> Sent: 10 December 2001 22:36
>>> Sander Striker wrote:
>>>> Hi,
>>>> This is the code with the latest changes based on comments
>>>> from various people.
>>>> I have yet to begin to start coding/migrating the debug
>>>> code.  I won't have time to complete that until at least
>>>> next week.  Bill (wrowe) can you live without that for
>>>> a little while?  I specifically ask because you have
>>>> recently added a bunch of debug code to pools.
>>> I can try to add in the debug code this week. 
>> Could we sync thoughts on how to do it?
>> I would very much like to split out the common code between
>> debug and production into a seperate file, and have both the
>> debug specific and the production only code in another.
>> This hopefully keeps the production code clean and readable.
> Good point, and now that I've had a chance to study
> the debug code some more, I think it will take some
> more planning to add it into the new pools code.  The
> problem is that a lot of the debug code for joining
> pools is dependent on having a single free list.  Do
> you have a design in mind for making the debug code
> work with the new allocator system?

I had the idea to not use the allocator system or any of the
production pools code while debugging.  The debug code
will just use malloc/free instead.  In debug mode speed
isn't important anyway :)

Hmm, we could opt for two versions: let node_malloc
and node_free just do malloc and free, and let apr_palloc
and apr_pool_clear/apr_pool_destroy use malloc/free.

I do realise that this will leave the regular pools code
untouched while debugging, which is the downside to doing
it that way.

What are your thoughts on the matter?

> --Brian


View raw message