> > 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
