On Thu, May 10, 2001 at 07:31:08AM -0500, William A. Rowe, Jr. wrote: > From: "Luke Kenneth Casson Leighton" <[EMAIL PROTECTED]> > 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 child. > 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! luke
