> 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
Sander