> > You will need the same kind of thing for stackable memory systems > > -- there > > needs to be a way for a developer to ensure that data allocated within a > > data structure is as long-lived as the data structure itself. > > Could you expand on this? Ie, give a small example (I probably have in > my head what you mean, but I want to make sure)?
roy, you're referring to apr_pool_join(), yes? you'd like, i presume, something like apr_memsys_join()? i'd far rather that it was simply stated, up front: 'for apr_memsys instances, there is no guarantee regarding the ordering of destruction / reset for memory allocated from a memsys instance' effectively, any memory allocated from an apr_memsys instance is 'on its own'. for the convenience of that bit of memory, in its own little world, there happens to be a mechanism to associate a cleanup function with it, but that's all. for example, what happens if someone implements a kernel page apr_memsys? you never free memory, there, you simply mark the page as dirty, and the hardware does the rest. _you_ wanna track that? :) :) okay, being a bit less ruthless / relentless: 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). luke
