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 10:58:42 GMT
> > 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

Mime
View raw message