apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: APR shared memory requirements.
Date Wed, 09 May 2001 19:51:50 GMT
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

> 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

... or do i not get it, yet? :)


View raw message