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
