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 Thu, 10 May 2001 13:09:20 GMT
On Thu, May 10, 2001 at 07:31:08AM -0500, William A. Rowe, Jr. wrote:

> From: "Luke Kenneth Casson Leighton" <lkcl@samba-tng.org>
> Sent: Thursday, May 10, 2001 5:58 AM
> > the idea of providing an independent apr_memsys_join() with
> > totally separate memory, totally separate semantics, that can
> > cope with totally alien apr_memsys instances, thereby
> > guaranteeing you destruction ordering / dependencies, seems
> > like something that you clearly perceive there is a need for,
> > that also keeps me happy.
> > 
> > the same principle applies to apr_pool_join() (see other message).
> Why not simply register a cleanup of one memsys for it's (newborn)
> child?

urr... *thinks*...

in what way?

i mean, you can register a cleanup with memory associated
with memory allocated _from_ a memsys.

what we intended to do was to implement apr_pool to use an
apr_memsys instance instead of hard-coding malloc/free in it.

at that time, you can associate a memsys cleanup,
in the apr_pool_initialise(), that calls apr_pool_destroy(),
which will call pool destruction
on all memory in the pool, and once _that's_ done, the memsys
will free the memory fragments used by that pool.

so, if you decide to destroy a memsys instance, and there
_happen_ to be some pools created from it (independent
or otherwise), they will all have apr_pool_destroy()
called on them, and everybody's happy.

... right? [please say yes, please say yes, please tell
me you don't want apr_memsys_join() guarantees :) ]

so, when you say child, well... there aren't any?

either that, or i am misunderstanding what you mean by

> I would _hope_ we are implementing cleanups in all memory
> models, since this is absolutely an essential feature.
that's up to the implementors (developers) of each memsys model :)
essential as it may be :)

> One aspect of shmem/mmap cleanups, well, we actually have two different
> types of cleanups.  One is the 'destructor', the other a 'detach'.

could you possibly explain that further.

currently, we have reset and destroy.  reset just trashes everything
but 'resets' it back to as if you had just created the memsys instance.

destroy does the same but then is responsible for destroying itself
as well.

> Of course, if multiple, disparate apps share the same shmem/mmap cleanups,
> it's up to them to agree on the destructor semantic.  No promises that 
> the 'last one out the door, turn out the lights' knows which light switch 
> to turn out :-)


which is why i am nervous about apr_pool_join() and apr_memsys_join().

but then again, it might be that i am nervous about the
implications of _not_ having those functions, i haven't quite
worked out which!


View raw message