On Wed, May 09, 2001 at 11:41:18AM -0700, dean gaudet wrote: > i dunno, i think you either don't understand ap_pool_join, or something is
[i don't - yet. your message makes it clearer, though: thanks!] > totally fucked up with it in 2.0. i wouldn't be surprised if it's that [no it isn't] > 2.0's POOL_DEBUG code is broken... go look at 1.3 and see if it makes more > sense. [your message makes more sense than the code :)] > 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. my point is that if you _don't_ #define POOL_DEBUG, this _isn't_ a problem??? > 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. uhh, they may be hierarchical, however they all allocate from the same memory, using a static 'management' list. the 'management' memory for pools most definitely is _not_ hierarchical. ...or, maybe, a better word to use here is 'stackable', not 'hierarchical'. [a la apr_memsys: stackable memory system we're putting together]. therein lies my difficulty with this. if you consider doing 'stackable' memory systems, where you have two pools that allocate from two totally different memory systems, they can _not_ be apr_pool_join()ed, end of story. only when you can guarantee that the pools came from the same stackable memory system instance can you start to think about doing pool joining. something to think about: do the possible risks of allowing someone to attempt an apr_pool_join() between a pool that was allocated from shared memory and another from thread-locked standard system memory, outweigh the benefits of apr_pool_join(), or is it better to force people to do a little extra work in the way they do pool allocation and management (e.g. create two totally separate pool instances from two separate apr_memsys_standard_memory() instances, and destroy them separately and manually, in the correct order), such that the apr_pool_join() function can be dropped? > 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". that may be the case, however when you don't enable POOL_DEBUG, it doesn't _do_ anything! the guarantees, esp. if the behaviour of the program is affected _by_ enabling POOL_DEBUG, are almost worthless. ... or do i not get it, yet? :) lukes
