i dunno, i think you either don't understand ap_pool_join, or something is totally fucked up with it in 2.0. i wouldn't be surprised if it's that 2.0's POOL_DEBUG code is broken... go look at 1.3 and see if it makes more sense.
On Wed, 9 May 2001, Luke Kenneth Casson Leighton wrote: > > > p.s. please please please can apr_pool_join() be dropped? :) > > > > I don't think so! Why do you want it to be? > > lots of reasons. > > 1) it's only enabled in debug mode > > 2) when i reviewed it [ 2 months ago], i think i noticed that it > has side-effects. ... IIRC, if you compile in debug > mode, it acts as expected: merges all call-backs into the > parent pool > > if you DON'T compile in debug mode, where you DO need to find > problems, then because it does nothing, you end up not detecting > them! > > 3) as i understand it, its description has nothing to do with what > it actually does. try making it a NOP and run the pool debugging in 1.3 and test the modules where the joins occur and then follow the logic and you'll probably see why it's there. i've no idea if the debugging facility even works in 2.0 (or if the comments were transferred correctly, or ...) > 4) it's only called in two places. > > 5) it's in the way of being able to turn apr_pool from a flat, > global-based memory system into a truly hierarchical one. pools were never flat, they were hierarchical. the whole point of ap_pool_join is that you're violating the normal hierarchy, and the ap_pool_join is there to say "i know what i'm doing, i'm guaranteeing i won't be violating the nested lifetimes properties". the comment for ap_pool_join in 1.3 starts with "pools have nested lifetimes". that is the hierarchy. -dean
