> From: Brian Pane [mailto:[EMAIL PROTECTED] > Sent: 11 December 2001 18:21 > Sander Striker wrote: > >>> From: Brian Pane [ mailto:[EMAIL PROTECTED] >>> 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
