You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by rb...@covalent.net on 2001/05/01 17:49:43 UTC
APR shared memory requirements.
Most people have realized that APR's shared memory support isn't good
enough to support Apache, or in reality most other applications. We had
this discussion during the hack-a-thon, and we came up with a small list
of requirements for APR's new shared memory implementation. Here are the
notes:
1) malloc-like implementation
2) Anonymous and Key based shared memory support
3) Def-ref macros (these must use double indirection)
4) Reference counting
5) Cleanups that use the pool implementation
That's it. In reality, even our current API isn't good enough to do what
we need, so people who wish to implement should feel free to re-implement
the API. As the first note in this list says, it should look a lot like
malloc() if at all possible.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: APR shared memory requirements.
Posted by dean gaudet <dg...@arctic.org>.
On Thu, 10 May 2001, Luke Kenneth Casson Leighton wrote:
> my concern is that apr_pool_join() is going to get in the way
> or going to get very confusing.
well, i created it as part of debugging 1.3, it may make sense to
reformulate the debugging approach to APR memory. now that i'm convinced
you understand what's going on, i'm cool with you doing whatever makes you
and the other active developers happy :)
-dean
Re: APR shared memory requirements.
Posted by dean gaudet <dg...@arctic.org>.
On Thu, 10 May 2001, Luke Kenneth Casson Leighton wrote:
> my concern is that apr_pool_join() is going to get in the way
> or going to get very confusing.
well, i created it as part of debugging 1.3, it may make sense to
reformulate the debugging approach to APR memory. now that i'm convinced
you understand what's going on, i'm cool with you doing whatever makes you
and the other active developers happy :)
-dean
Re: APR shared memory requirements.
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Wed, May 09, 2001 at 06:48:42PM -0700, dean gaudet wrote:
>
>
> On Wed, 9 May 2001, Luke Kenneth Casson Leighton wrote:
>
> > my point is that if you _don't_ #define POOL_DEBUG, this _isn't_ a
> > problem???
>
> nope -- the ap_pool_join() is a promise by the caller that they won't
> destroy pool B prior to destroying pool A. well, if you think of this in
> terms of 1.3, which never shares pooled data between threads, what i'm
> really saying is that none of the structures (such as tables) which have
> data allocated in both pools A and B won't be accessed after B has been
> destroyed.
so, it's a way to avoid having to do reference counting.
> typically B is a sub-pool of A even in these cases, but sub-pools can
> theoretically be freed before the parent -- and if you have a table
> allocated in A which has pointers to data in B then this results in memory
> corruption.
okay. so you have two separate pools. they even come from different
management structures.
example. you have one apr_pool whose memory is allocated from an
apr_memsys that does page-locking for you, guaranteeing that the
memory never hits disk.
you have another apr_pool that allocates from a standard apr_memsys.
and, maybe you have another apr_pool that allocates from a shared
memory apr_memsys.
you _know_ that these three alien memory systems are distinct
and separate, yet for some reason, you use the standard pool
to store a large linked list (or table) of your precious page-locked
pool data (which may be GPG private keys or some-such), etc. etc.
for each memory system, which have destroy methods on all allocations
by the way, you must explicity call the apr_memsys_destroy() when
you are totally finished with them.
and you explicitly do so in the correct order that guarantees the same
promise as apr_pool_join(), except one level above.
> so the debugging code is there to test that when you do this A/B thing
> that you either get a warning, or the code in question needs to make the
> "ap_pool_join promise".
>
> if you look at the ap_pool_join code you'll see that the side-effect it
> has only modifies data which is present when POOL_DEBUG is active.
ack. very impressed. not only were you able to answer my question
which was formed from unclear understanding and issues i've only
heard of, but also to back it up in a way that will reassure others
who understand this clearer than i.
> > uhh, they may be hierarchical, however they all allocate from the
> > same memory, using a static 'management' list. the 'management' memory
> > for pools most definitely is _not_ hierarchical.
>
> the block list you mean? yeah, no hierarchy there. (and it's strictly
> not required by the pool API, it's a behind-the-scenes optimisation.)
ack.
> > ...or, maybe, a better word to use here is 'stackable', not 'hierarchical'.
> > [a la apr_memsys: stackable memory system we're putting together].
>
> in OO lingo you mean inheritance right?
... not quite. imagine replacing the free and malloc routines in
apr_pool.c with library routines (apr_memsys library routines,
to be more precise).
then, imagine that those library routines are actually ap_pool_alloc
and friends :)
[it's a little more involved than that, but you get the idea :) ]
my concern is that apr_pool_join() is going to get in the way
or going to get very confusing.
> > therein lies my difficulty with this. if you consider doing
> > 'stackable' memory systems, where you have two pools that
> > allocate from two totally different memory systems, they can _not_
> > be apr_pool_join()ed, end of story.
>
> why not?
>
> you can still promise that you won't free pool B before you're done using
> cross-pool structures. ap_pool_join() is a statement about the lifetime
> of those two pools (and this is what my comments in the code try to
> explain).
see above: when one pool is allocated from a totally different
set of 'management' structures - no static lists any more in apr_pool.c,
it's in a 'management' stackable memory system instead - then
the thought of someone trying to do an apr_pool_join() on two
utterly alien apr_pool_t instances just...
i don't know what to suggest! if you can live with it, fine.
if not, apr_pool_join() should really die.
> of course it's pretty hard to make this promise if one of the pools has
> global lifetime, and is accessed by multiple threads. this is possible in
> 2.0 now isn't it? i think that's a mistake if so :) amongst the many
> features of 1.3 pools were that they were single-threaded access, zero
> mutexes required on the fast path.
>
> but if one of the pools has a global lifetime, and the other doesn't, then
> you shouldn't be making the ap_pool_join() promise, and so there's no
> problem with the function.
>
> if you want to continue to support POOL_DEBUG (i am really so far out of
> date with 2.0 internals now that i can't make a judgement on how useful it
> is), then i suspect what you need to do is provide a private function
> which, when given a void *, returns what pool it belongs to. this would
> be implemented by all the pool classes.
>
> that handles the POOL_DEBUG stuff which is in the union block_hdr
> structure.
>
> the "joined" stuff shouldn't need to change, it should be same for all
> pool implementations.
okay. been thinking about this.
maybe this isn't such a bad idea.
... in the light of the above, where apr_pools may be totally
independent and utterly alien to each other, how could it be
implemented?
> note: i personally think that pools made sense in an http server for
> a few things (the fast path through static responses, and that's about
> it), but don't make any sense at all in pretty much every other program
> in existence, and i kind of question the abuses they're going through.
it makes a lot of sense in dce/rpc. also in samba TNG.
Re: APR shared memory requirements.
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Wed, May 09, 2001 at 06:48:42PM -0700, dean gaudet wrote:
>
>
> On Wed, 9 May 2001, Luke Kenneth Casson Leighton wrote:
>
> > my point is that if you _don't_ #define POOL_DEBUG, this _isn't_ a
> > problem???
>
> nope -- the ap_pool_join() is a promise by the caller that they won't
> destroy pool B prior to destroying pool A. well, if you think of this in
> terms of 1.3, which never shares pooled data between threads, what i'm
> really saying is that none of the structures (such as tables) which have
> data allocated in both pools A and B won't be accessed after B has been
> destroyed.
so, it's a way to avoid having to do reference counting.
> typically B is a sub-pool of A even in these cases, but sub-pools can
> theoretically be freed before the parent -- and if you have a table
> allocated in A which has pointers to data in B then this results in memory
> corruption.
okay. so you have two separate pools. they even come from different
management structures.
example. you have one apr_pool whose memory is allocated from an
apr_memsys that does page-locking for you, guaranteeing that the
memory never hits disk.
you have another apr_pool that allocates from a standard apr_memsys.
and, maybe you have another apr_pool that allocates from a shared
memory apr_memsys.
you _know_ that these three alien memory systems are distinct
and separate, yet for some reason, you use the standard pool
to store a large linked list (or table) of your precious page-locked
pool data (which may be GPG private keys or some-such), etc. etc.
for each memory system, which have destroy methods on all allocations
by the way, you must explicity call the apr_memsys_destroy() when
you are totally finished with them.
and you explicitly do so in the correct order that guarantees the same
promise as apr_pool_join(), except one level above.
> so the debugging code is there to test that when you do this A/B thing
> that you either get a warning, or the code in question needs to make the
> "ap_pool_join promise".
>
> if you look at the ap_pool_join code you'll see that the side-effect it
> has only modifies data which is present when POOL_DEBUG is active.
ack. very impressed. not only were you able to answer my question
which was formed from unclear understanding and issues i've only
heard of, but also to back it up in a way that will reassure others
who understand this clearer than i.
> > uhh, they may be hierarchical, however they all allocate from the
> > same memory, using a static 'management' list. the 'management' memory
> > for pools most definitely is _not_ hierarchical.
>
> the block list you mean? yeah, no hierarchy there. (and it's strictly
> not required by the pool API, it's a behind-the-scenes optimisation.)
ack.
> > ...or, maybe, a better word to use here is 'stackable', not 'hierarchical'.
> > [a la apr_memsys: stackable memory system we're putting together].
>
> in OO lingo you mean inheritance right?
... not quite. imagine replacing the free and malloc routines in
apr_pool.c with library routines (apr_memsys library routines,
to be more precise).
then, imagine that those library routines are actually ap_pool_alloc
and friends :)
[it's a little more involved than that, but you get the idea :) ]
my concern is that apr_pool_join() is going to get in the way
or going to get very confusing.
> > therein lies my difficulty with this. if you consider doing
> > 'stackable' memory systems, where you have two pools that
> > allocate from two totally different memory systems, they can _not_
> > be apr_pool_join()ed, end of story.
>
> why not?
>
> you can still promise that you won't free pool B before you're done using
> cross-pool structures. ap_pool_join() is a statement about the lifetime
> of those two pools (and this is what my comments in the code try to
> explain).
see above: when one pool is allocated from a totally different
set of 'management' structures - no static lists any more in apr_pool.c,
it's in a 'management' stackable memory system instead - then
the thought of someone trying to do an apr_pool_join() on two
utterly alien apr_pool_t instances just...
i don't know what to suggest! if you can live with it, fine.
if not, apr_pool_join() should really die.
> of course it's pretty hard to make this promise if one of the pools has
> global lifetime, and is accessed by multiple threads. this is possible in
> 2.0 now isn't it? i think that's a mistake if so :) amongst the many
> features of 1.3 pools were that they were single-threaded access, zero
> mutexes required on the fast path.
>
> but if one of the pools has a global lifetime, and the other doesn't, then
> you shouldn't be making the ap_pool_join() promise, and so there's no
> problem with the function.
>
> if you want to continue to support POOL_DEBUG (i am really so far out of
> date with 2.0 internals now that i can't make a judgement on how useful it
> is), then i suspect what you need to do is provide a private function
> which, when given a void *, returns what pool it belongs to. this would
> be implemented by all the pool classes.
>
> that handles the POOL_DEBUG stuff which is in the union block_hdr
> structure.
>
> the "joined" stuff shouldn't need to change, it should be same for all
> pool implementations.
okay. been thinking about this.
maybe this isn't such a bad idea.
... in the light of the above, where apr_pools may be totally
independent and utterly alien to each other, how could it be
implemented?
> note: i personally think that pools made sense in an http server for
> a few things (the fast path through static responses, and that's about
> it), but don't make any sense at all in pretty much every other program
> in existence, and i kind of question the abuses they're going through.
it makes a lot of sense in dce/rpc. also in samba TNG.
RE: APR shared memory requirements.
Posted by Sander Striker <st...@samba-tng.org>.
Ok, trying to shed some light on this, because I'm afraid people
are going to get confused.
>>> 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.
Actually, I don't think this is what Bill (how do you get from William
A. Rowe, Jr. to Bill??) meant.
We only support one type of cleanup function in the framework at the moment.
The cleanup functions are associated with a memory system instance
and called on _two_ occassions:
- whenever apr_memory_system_reset() is called on the memory system;
- whenever apr_memory_system_destroy() is called on the memory system.
So effectively apr_memory_system_reset() puts the memory system in the
state it was right after creation. It is therefor important _not_ to
register cleanup functions in the create when you implement a reset.
This implies that it is not wise to do so for any tracking memory
system (a catagory pools are definitely in).
If you really need two different types of cleanup functions there
are three options:
- associate a type with the cleanup function;
- implement a second registration function, etc. (this is what is done
in the pools code, personally, if needed I like option one better);
- Only implement it for a specific memory system.
For the record, a memory system instance that is the child of another
is _not_ guaranteed to have its reset or destroy function called. Since
these two functions are only allowed to do memory freeing, including
the memory system itself, they can be skipped by the parent if it is
tracking. [Hmmm, I might again have people lost now :-) ]
>> 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!
It is entirely up to the implementation of the memory system to take
care of this. In case of a shared memory system reference counting
would be the way to go (the refcount decrease should be done in
the pre_destroy). When the refcount hits zero you do the cleanups...
Argh, ok, this cannot be done with the code as such, I'll see what
can be done about this...
Thinking about this it is probably not wise to allow shared memory
systems to have a parent...
Ok, lets see the current order of events that take place when
destroy is called:
- all the cleanup functions of the children are called (this is
recursive, so the relative with the greatest distance has its
cleanups called first)
- right after the cleanup functions the pre_destroy functions of
the children are called
- all cleanup functions of the memory system itself are called
- the pre_destroy function of the memory system itself is called
- the destroy function of the memory system itself is called *)
*) This last step could be a number of things, but this is just
for clarification. When there is no destroy, the parents free
function is used.
Lets see the current order of events that take place when
reset is called *):
- all the cleanup functions of the children are called (this is
recursive, so the relative with the greatest distance has its
cleanups called first)
- right after the cleanup functions the pre_destroy functions of
the children are called
- all cleanup functions of the memory system itself are called
- the reset function of the memory system itself is called
*) This will only work on tracking memory systems, it is no point
(and there are no means) to reset a non tracking memory system;
this will only result in memory leaks.
Looking at this we might want to call and register cleanups of a
certain types: CLEANUP_ON_RESET, CLEANUP_ON_DESTROY, CLEANUP_ALWAYS.
This would render pre_destroy obsolete :-)
Oh, before I forget, the cleanups are 'last in - first called'.
Hope this helps a bit (it certainly did me), if you guys are interested
in typed cleanups I'm willing to provide a patch this weekend,
Sander
Re: APR shared memory requirements.
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Thu, May 10, 2001 at 07:31:08AM -0500, William A. Rowe, Jr. wrote:
> From: "Luke Kenneth Casson Leighton" <lk...@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
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
Re: APR shared memory requirements.
Posted by "William A. Rowe, Jr." <li...@rowe-clan.net>.
From: "Luke Kenneth Casson Leighton" <lk...@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? I would _hope_ we are implementing cleanups in all memory
models, since this is absolutely an essential feature.
One aspect of shmem/mmap cleanups, well, we actually have two different
types of cleanups. One is the 'destructor', the other a 'detach'.
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 :-)
Re: APR shared memory requirements.
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> > 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
Re: APR shared memory requirements.
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> > 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
RE: APR shared memory requirements.
Posted by Sander Striker <st...@samba-tng.org>.
>> that may be the case, however when you don't enable POOL_DEBUG,
>> it doesn't _do_ anything! the guarantees, esp. if the behaviour
>> of the program is affected _by_ enabling POOL_DEBUG, are almost
>> worthless.
Actually, the implementation of the memory system code depends
heavily on asserts and some debug code is only executed when
APR_MEMORY_SYSTEM_DEBUG is defined.
Maybe APR_MEMORY_SYSTEM_DEBUG should just be set when normal
debugging is enabled?
> They only do one thing -- they tell the maintainer that someone just
> committed something rather clueless. Dean (and myself when I had time)
> used to compile httpd 1.3 with ALLOC_DEBUG and POOL_DEBUG on all the time
> in order to catch places where modules were combining memory from multiple
> pools. It is not intended to be a run-time check for deployed systems
> because that would add pointless overhead (there is no recovery
> path anyway).
> It may not work right now in 2.0, since I recall someone monkeying with
> the code because it wasn't thread-safe.
>
> 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
Sander
Re: APR shared memory requirements.
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> that may be the case, however when you don't enable POOL_DEBUG,
> it doesn't _do_ anything! the guarantees, esp. if the behaviour
> of the program is affected _by_ enabling POOL_DEBUG, are almost
> worthless.
They only do one thing -- they tell the maintainer that someone just
committed something rather clueless. Dean (and myself when I had time)
used to compile httpd 1.3 with ALLOC_DEBUG and POOL_DEBUG on all the time
in order to catch places where modules were combining memory from multiple
pools. It is not intended to be a run-time check for deployed systems
because that would add pointless overhead (there is no recovery path anyway).
It may not work right now in 2.0, since I recall someone monkeying with
the code because it wasn't thread-safe.
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.
....Roy
Re: APR shared memory requirements.
Posted by dean gaudet <dg...@arctic.org>.
On Wed, 9 May 2001, Luke Kenneth Casson Leighton wrote:
> my point is that if you _don't_ #define POOL_DEBUG, this _isn't_ a
> problem???
nope -- the ap_pool_join() is a promise by the caller that they won't
destroy pool B prior to destroying pool A. well, if you think of this in
terms of 1.3, which never shares pooled data between threads, what i'm
really saying is that none of the structures (such as tables) which have
data allocated in both pools A and B won't be accessed after B has been
destroyed.
typically B is a sub-pool of A even in these cases, but sub-pools can
theoretically be freed before the parent -- and if you have a table
allocated in A which has pointers to data in B then this results in memory
corruption.
so the debugging code is there to test that when you do this A/B thing
that you either get a warning, or the code in question needs to make the
"ap_pool_join promise".
if you look at the ap_pool_join code you'll see that the side-effect it
has only modifies data which is present when POOL_DEBUG is active.
> uhh, they may be hierarchical, however they all allocate from the
> same memory, using a static 'management' list. the 'management' memory
> for pools most definitely is _not_ hierarchical.
the block list you mean? yeah, no hierarchy there. (and it's strictly
not required by the pool API, it's a behind-the-scenes optimisation.)
> ...or, maybe, a better word to use here is 'stackable', not 'hierarchical'.
> [a la apr_memsys: stackable memory system we're putting together].
in OO lingo you mean inheritance right?
> therein lies my difficulty with this. if you consider doing
> 'stackable' memory systems, where you have two pools that
> allocate from two totally different memory systems, they can _not_
> be apr_pool_join()ed, end of story.
why not?
you can still promise that you won't free pool B before you're done using
cross-pool structures. ap_pool_join() is a statement about the lifetime
of those two pools (and this is what my comments in the code try to
explain).
of course it's pretty hard to make this promise if one of the pools has
global lifetime, and is accessed by multiple threads. this is possible in
2.0 now isn't it? i think that's a mistake if so :) amongst the many
features of 1.3 pools were that they were single-threaded access, zero
mutexes required on the fast path.
but if one of the pools has a global lifetime, and the other doesn't, then
you shouldn't be making the ap_pool_join() promise, and so there's no
problem with the function.
if you want to continue to support POOL_DEBUG (i am really so far out of
date with 2.0 internals now that i can't make a judgement on how useful it
is), then i suspect what you need to do is provide a private function
which, when given a void *, returns what pool it belongs to. this would
be implemented by all the pool classes.
that handles the POOL_DEBUG stuff which is in the union block_hdr
structure.
the "joined" stuff shouldn't need to change, it should be same for all
pool implementations.
note: i personally think that pools made sense in an http server for
a few things (the fast path through static responses, and that's about
it), but don't make any sense at all in pretty much every other program
in existence, and i kind of question the abuses they're going through.
-dean
Re: APR shared memory requirements.
Posted by dean gaudet <dg...@arctic.org>.
On Wed, 9 May 2001, Luke Kenneth Casson Leighton wrote:
> my point is that if you _don't_ #define POOL_DEBUG, this _isn't_ a
> problem???
nope -- the ap_pool_join() is a promise by the caller that they won't
destroy pool B prior to destroying pool A. well, if you think of this in
terms of 1.3, which never shares pooled data between threads, what i'm
really saying is that none of the structures (such as tables) which have
data allocated in both pools A and B won't be accessed after B has been
destroyed.
typically B is a sub-pool of A even in these cases, but sub-pools can
theoretically be freed before the parent -- and if you have a table
allocated in A which has pointers to data in B then this results in memory
corruption.
so the debugging code is there to test that when you do this A/B thing
that you either get a warning, or the code in question needs to make the
"ap_pool_join promise".
if you look at the ap_pool_join code you'll see that the side-effect it
has only modifies data which is present when POOL_DEBUG is active.
> uhh, they may be hierarchical, however they all allocate from the
> same memory, using a static 'management' list. the 'management' memory
> for pools most definitely is _not_ hierarchical.
the block list you mean? yeah, no hierarchy there. (and it's strictly
not required by the pool API, it's a behind-the-scenes optimisation.)
> ...or, maybe, a better word to use here is 'stackable', not 'hierarchical'.
> [a la apr_memsys: stackable memory system we're putting together].
in OO lingo you mean inheritance right?
> therein lies my difficulty with this. if you consider doing
> 'stackable' memory systems, where you have two pools that
> allocate from two totally different memory systems, they can _not_
> be apr_pool_join()ed, end of story.
why not?
you can still promise that you won't free pool B before you're done using
cross-pool structures. ap_pool_join() is a statement about the lifetime
of those two pools (and this is what my comments in the code try to
explain).
of course it's pretty hard to make this promise if one of the pools has
global lifetime, and is accessed by multiple threads. this is possible in
2.0 now isn't it? i think that's a mistake if so :) amongst the many
features of 1.3 pools were that they were single-threaded access, zero
mutexes required on the fast path.
but if one of the pools has a global lifetime, and the other doesn't, then
you shouldn't be making the ap_pool_join() promise, and so there's no
problem with the function.
if you want to continue to support POOL_DEBUG (i am really so far out of
date with 2.0 internals now that i can't make a judgement on how useful it
is), then i suspect what you need to do is provide a private function
which, when given a void *, returns what pool it belongs to. this would
be implemented by all the pool classes.
that handles the POOL_DEBUG stuff which is in the union block_hdr
structure.
the "joined" stuff shouldn't need to change, it should be same for all
pool implementations.
note: i personally think that pools made sense in an http server for
a few things (the fast path through static responses, and that's about
it), but don't make any sense at all in pretty much every other program
in existence, and i kind of question the abuses they're going through.
-dean
Re: APR shared memory requirements.
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Wed, May 09, 2001 at 11:41:18AM -0700, dean gaudet wrote:
> i dunno, i think you either don't understand ap_pool_join, or something is
[i don't - yet. your message makes it clearer, though: thanks!]
> totally fucked up with it in 2.0. i wouldn't be surprised if it's that
[no it isn't]
> 2.0's POOL_DEBUG code is broken... go look at 1.3 and see if it makes more
> sense.
[your message makes more sense than the code :)]
> try making it a NOP and run the pool debugging in 1.3 and test the modules
> where the joins occur and then follow the logic and you'll probably see
> why it's there.
my point is that if you _don't_ #define POOL_DEBUG, this _isn't_ a
problem???
> i've no idea if the debugging facility even works in 2.0 (or if the
> comments were transferred correctly, or ...)
>
> > 4) it's only called in two places.
> >
> > 5) it's in the way of being able to turn apr_pool from a flat,
> > global-based memory system into a truly hierarchical one.
>
> pools were never flat, they were hierarchical.
uhh, they may be hierarchical, however they all allocate from the
same memory, using a static 'management' list. the 'management' memory
for pools most definitely is _not_ hierarchical.
...or, maybe, a better word to use here is 'stackable', not 'hierarchical'.
[a la apr_memsys: stackable memory system we're putting together].
therein lies my difficulty with this. if you consider doing
'stackable' memory systems, where you have two pools that
allocate from two totally different memory systems, they can _not_
be apr_pool_join()ed, end of story.
only when you can guarantee that the pools came from the same
stackable memory system instance can you start to think about
doing pool joining.
something to think about: do the possible risks of allowing someone
to attempt an apr_pool_join() between a pool that was allocated
from shared memory and another from thread-locked standard system
memory, outweigh the benefits of apr_pool_join(), or is it better
to force people to do a little extra work in the way they
do pool allocation and management (e.g. create two totally separate
pool instances from two separate apr_memsys_standard_memory()
instances, and destroy them separately and manually, in the correct
order), such that the apr_pool_join() function can be dropped?
> the whole point of
> ap_pool_join is that you're violating the normal hierarchy, and the
> ap_pool_join is there to say "i know what i'm doing, i'm guaranteeing i
> won't be violating the nested lifetimes properties".
that may be the case, however when you don't enable POOL_DEBUG,
it doesn't _do_ anything! the guarantees, esp. if the behaviour
of the program is affected _by_ enabling POOL_DEBUG, are almost
worthless.
... or do i not get it, yet? :)
lukes
Re: APR shared memory requirements.
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Wed, May 09, 2001 at 11:41:18AM -0700, dean gaudet wrote:
> i dunno, i think you either don't understand ap_pool_join, or something is
[i don't - yet. your message makes it clearer, though: thanks!]
> totally fucked up with it in 2.0. i wouldn't be surprised if it's that
[no it isn't]
> 2.0's POOL_DEBUG code is broken... go look at 1.3 and see if it makes more
> sense.
[your message makes more sense than the code :)]
> try making it a NOP and run the pool debugging in 1.3 and test the modules
> where the joins occur and then follow the logic and you'll probably see
> why it's there.
my point is that if you _don't_ #define POOL_DEBUG, this _isn't_ a
problem???
> i've no idea if the debugging facility even works in 2.0 (or if the
> comments were transferred correctly, or ...)
>
> > 4) it's only called in two places.
> >
> > 5) it's in the way of being able to turn apr_pool from a flat,
> > global-based memory system into a truly hierarchical one.
>
> pools were never flat, they were hierarchical.
uhh, they may be hierarchical, however they all allocate from the
same memory, using a static 'management' list. the 'management' memory
for pools most definitely is _not_ hierarchical.
...or, maybe, a better word to use here is 'stackable', not 'hierarchical'.
[a la apr_memsys: stackable memory system we're putting together].
therein lies my difficulty with this. if you consider doing
'stackable' memory systems, where you have two pools that
allocate from two totally different memory systems, they can _not_
be apr_pool_join()ed, end of story.
only when you can guarantee that the pools came from the same
stackable memory system instance can you start to think about
doing pool joining.
something to think about: do the possible risks of allowing someone
to attempt an apr_pool_join() between a pool that was allocated
from shared memory and another from thread-locked standard system
memory, outweigh the benefits of apr_pool_join(), or is it better
to force people to do a little extra work in the way they
do pool allocation and management (e.g. create two totally separate
pool instances from two separate apr_memsys_standard_memory()
instances, and destroy them separately and manually, in the correct
order), such that the apr_pool_join() function can be dropped?
> the whole point of
> ap_pool_join is that you're violating the normal hierarchy, and the
> ap_pool_join is there to say "i know what i'm doing, i'm guaranteeing i
> won't be violating the nested lifetimes properties".
that may be the case, however when you don't enable POOL_DEBUG,
it doesn't _do_ anything! the guarantees, esp. if the behaviour
of the program is affected _by_ enabling POOL_DEBUG, are almost
worthless.
... or do i not get it, yet? :)
lukes
Re: APR shared memory requirements.
Posted by dean gaudet <dg...@arctic.org>.
i dunno, i think you either don't understand ap_pool_join, or something is
totally fucked up with it in 2.0. i wouldn't be surprised if it's that
2.0's POOL_DEBUG code is broken... go look at 1.3 and see if it makes more
sense.
On Wed, 9 May 2001, Luke Kenneth Casson Leighton wrote:
> > > p.s. please please please can apr_pool_join() be dropped? :)
> >
> > I don't think so! Why do you want it to be?
>
> lots of reasons.
>
> 1) it's only enabled in debug mode
>
> 2) when i reviewed it [ 2 months ago], i think i noticed that it
> has side-effects. ... IIRC, if you compile in debug
> mode, it acts as expected: merges all call-backs into the
> parent pool
>
> if you DON'T compile in debug mode, where you DO need to find
> problems, then because it does nothing, you end up not detecting
> them!
>
> 3) as i understand it, its description has nothing to do with what
> it actually does.
try making it a NOP and run the pool debugging in 1.3 and test the modules
where the joins occur and then follow the logic and you'll probably see
why it's there.
i've no idea if the debugging facility even works in 2.0 (or if the
comments were transferred correctly, or ...)
> 4) it's only called in two places.
>
> 5) it's in the way of being able to turn apr_pool from a flat,
> global-based memory system into a truly hierarchical one.
pools were never flat, they were hierarchical. the whole point of
ap_pool_join is that you're violating the normal hierarchy, and the
ap_pool_join is there to say "i know what i'm doing, i'm guaranteeing i
won't be violating the nested lifetimes properties".
the comment for ap_pool_join in 1.3 starts with "pools have nested
lifetimes". that is the hierarchy.
-dean
Re: APR shared memory requirements.
Posted by dean gaudet <dg...@arctic.org>.
i dunno, i think you either don't understand ap_pool_join, or something is
totally fucked up with it in 2.0. i wouldn't be surprised if it's that
2.0's POOL_DEBUG code is broken... go look at 1.3 and see if it makes more
sense.
On Wed, 9 May 2001, Luke Kenneth Casson Leighton wrote:
> > > p.s. please please please can apr_pool_join() be dropped? :)
> >
> > I don't think so! Why do you want it to be?
>
> lots of reasons.
>
> 1) it's only enabled in debug mode
>
> 2) when i reviewed it [ 2 months ago], i think i noticed that it
> has side-effects. ... IIRC, if you compile in debug
> mode, it acts as expected: merges all call-backs into the
> parent pool
>
> if you DON'T compile in debug mode, where you DO need to find
> problems, then because it does nothing, you end up not detecting
> them!
>
> 3) as i understand it, its description has nothing to do with what
> it actually does.
try making it a NOP and run the pool debugging in 1.3 and test the modules
where the joins occur and then follow the logic and you'll probably see
why it's there.
i've no idea if the debugging facility even works in 2.0 (or if the
comments were transferred correctly, or ...)
> 4) it's only called in two places.
>
> 5) it's in the way of being able to turn apr_pool from a flat,
> global-based memory system into a truly hierarchical one.
pools were never flat, they were hierarchical. the whole point of
ap_pool_join is that you're violating the normal hierarchy, and the
ap_pool_join is there to say "i know what i'm doing, i'm guaranteeing i
won't be violating the nested lifetimes properties".
the comment for ap_pool_join in 1.3 starts with "pools have nested
lifetimes". that is the hierarchy.
-dean
Re: APR shared memory requirements.
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> > p.s. please please please can apr_pool_join() be dropped? :)
>
> I don't think so! Why do you want it to be?
lots of reasons.
1) it's only enabled in debug mode
2) when i reviewed it [ 2 months ago], i think i noticed that it
has side-effects. ... IIRC, if you compile in debug
mode, it acts as expected: merges all call-backs into the
parent pool
if you DON'T compile in debug mode, where you DO need to find
problems, then because it does nothing, you end up not detecting
them!
3) as i understand it, its description has nothing to do with what
it actually does.
4) it's only called in two places.
5) it's in the way of being able to turn apr_pool from a flat,
global-based memory system into a truly hierarchical one.
luke
Re: APR shared memory requirements.
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> > p.s. please please please can apr_pool_join() be dropped? :)
>
> I don't think so! Why do you want it to be?
lots of reasons.
1) it's only enabled in debug mode
2) when i reviewed it [ 2 months ago], i think i noticed that it
has side-effects. ... IIRC, if you compile in debug
mode, it acts as expected: merges all call-backs into the
parent pool
if you DON'T compile in debug mode, where you DO need to find
problems, then because it does nothing, you end up not detecting
them!
3) as i understand it, its description has nothing to do with what
it actually does.
4) it's only called in two places.
5) it's in the way of being able to turn apr_pool from a flat,
global-based memory system into a truly hierarchical one.
luke
Re: APR shared memory requirements.
Posted by Ben Laurie <be...@algroup.co.uk>.
Luke Kenneth Casson Leighton wrote:
>
> > > in this way, you could pass in a shmem-SMS-parent allocator
> > > to apr_pool_create(), and it will create a shared memory
> > > pool that looks, to all intents and purposes, like an apr_pool_t.
> > >
> > > interested?
> >
> > This sounds very cool. Certainly I'm interested.
>
> great-stuff. continue on dev@apr.apache.org?
Sure.
> have some
> ideas on how to proceed on devel of an apr_memsys_shmem.
>
> luke
>
> p.s. please please please can apr_pool_join() be dropped? :)
I don't think so! Why do you want it to be?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: APR shared memory requirements.
Posted by Ben Laurie <be...@algroup.co.uk>.
Luke Kenneth Casson Leighton wrote:
>
> > > in this way, you could pass in a shmem-SMS-parent allocator
> > > to apr_pool_create(), and it will create a shared memory
> > > pool that looks, to all intents and purposes, like an apr_pool_t.
> > >
> > > interested?
> >
> > This sounds very cool. Certainly I'm interested.
>
> great-stuff. continue on dev@apr.apache.org?
Sure.
> have some
> ideas on how to proceed on devel of an apr_memsys_shmem.
>
> luke
>
> p.s. please please please can apr_pool_join() be dropped? :)
I don't think so! Why do you want it to be?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: APR memory systems
Posted by Elrond <el...@samba-tng.org>.
On Wed, May 09, 2001 at 12:43:22PM +0200, Luke Kenneth Casson Leighton wrote:
[...]
> there may be some code / techniques in samba that may
> be worth examining: this is not at all dis-similar
> to file locking, except it happens to be memory, not
> files.
[...]
Yeah. tdb (already mentioned) is used in Samba to fully
implement NT locks on top of posix locks.
I'm neither a locking expert, but I remember, this is
needed for the same reasons already mentioned: same process
locking overlapping areas, etc.
NT seems to handle this stuff (nearly) properly and Samba
(TNG) has to do this on top of posix locks (which seem to
have shortcomings), so it has to do things _like_
refcounting.
Just my 2 dirham. ;)
Elrond
Re: APR memory systems
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> >From recent input on this list it is clear that the
> current threadsafe_lock()/unlock() functions don't cut it.
> We will need to work out how these functions should look.
threadsafe_lock()/unlock() as a name is misleading.
sharing memory between processes, requiring locking,
is nothing to do with threads.
there may be some code / techniques in samba that may
be worth examining: this is not at all dis-similar
to file locking, except it happens to be memory, not
files.
... so they're shared, mmap'd, threaded, so what? it's
all the same... :)
lukes
RE: APR memory systems
Posted by Sander Striker <st...@samba-tng.org>.
> Suggestion...
>
> If we're going to have a whole load of different "plug-ins" for different
> types of memory allocation/viewing, and some of these will of course look
> different for different platforms, can we split out the "standard memory
> system" functions into their own file as well? That should help
> expose the
> build issues quicker and give the structure more beef.
>
> In other words, add a file (apr_standard_memory_system.c??) containing the
> standard functions,
> static void *apr_standard_memory_system_malloc(apr_memory_system_t
> *memory_system, size_t size)
>
> static void *apr_standard_memory_system_realloc(apr_memory_system_t
> *memory_system, void *mem, size_t size)
>
> static void apr_standard_memory_system_free(apr_memory_system_t
> *memory_system, void *mem)
>
> apr_status_t apr_standard_memory_system_create(apr_memory_system_t
> **memory_system)
Ok, that makes sense.
Sander
Re: APR memory systems
Posted by David Reid <dr...@jetnet.co.uk>.
Suggestion...
If we're going to have a whole load of different "plug-ins" for different
types of memory allocation/viewing, and some of these will of course look
different for different platforms, can we split out the "standard memory
system" functions into their own file as well? That should help expose the
build issues quicker and give the structure more beef.
In other words, add a file (apr_standard_memory_system.c??) containing the
standard functions,
static void *apr_standard_memory_system_malloc(apr_memory_system_t
*memory_system, size_t size)
static void *apr_standard_memory_system_realloc(apr_memory_system_t
*memory_system, void *mem, size_t size)
static void apr_standard_memory_system_free(apr_memory_system_t
*memory_system, void *mem)
apr_status_t apr_standard_memory_system_create(apr_memory_system_t
**memory_system)
david
> Hi everyone,
>
> Sorry for the version mix up. This one is clearly the
> latest, since it has some signs of our locking discussion
> in it.
> From recent input on this list it is clear that the
> current threadsafe_lock()/unlock() functions don't cut it.
> We will need to work out how these functions should look.
>
> I compile tested the code with gcc 2.95.2.1 on a
> custom linux system (kernel 2.4.2, glibc 2.2.2) without
> warnings.
>
> Second I compile tested the code on Windows 2000 SP1
> using VC++ 6.0 SP3 without warnings.
>
> Attached are the sources.
>
> apr_memory_system.[ch] core (using apr_stuff.h), includes
> standard memory system.
> apr_stuff.h hacked up include file to compile
> without APR
>
> I hope someone among you will fix up the include thingies :-)
>
> More attachments:
>
> apr_tracking_memory_system.[ch] example of a tracking
> memory system implementation.
>
>
> Sander
>
APR memory systems, requirements
Posted by Sander Striker <st...@samba-tng.org>.
Hello again,
To implement shared memory systems, locking is required.
Since memory systems are hiding everything from the user,
locking for allocation and freeing is also hidden.
This means that when a user does a global lock, and
then calls apr_memory_system_malloc() on a shared
memory system (or any memory system doing locking)
a deadlock will occur.
So, we are going to need smart, refcounting locking.
The smart part is in identifying the callers process/thread.
If the same caller locks, just bump the refcount and
return.
I'm not a locking expert and if I read correctly Ryan and
Greg are already on this, but I want to point out that
this is imho the only way to cleanly implement this
in a way a user doesn't have to twist his brain when
using shared memory :-)
Oh, before I forget, there are ofcourse two locking
issues:
- locking required for management (ie, malloc etc),
which is done by the memory system (the implementor
is responsible for this and should document it).
Effectively a user doesn't see this and shouldn't
have to worry about it.
- locking required for accessing the memory.
The user has to explicitly call apr_memory_system_lock()
(to be defined and implemented) for this. In
case of a non locking memory system this function
just does nothing and returns. In the case of a
locking memory system the function calls the
memory system specific lock function (which has
to be provided by the memory system implementor).
Sander
APR memory systems
Posted by Sander Striker <st...@samba-tng.org>.
Hi everyone,
Sorry for the version mix up. This one is clearly the
latest, since it has some signs of our locking discussion
in it.
>From recent input on this list it is clear that the
current threadsafe_lock()/unlock() functions don't cut it.
We will need to work out how these functions should look.
I compile tested the code with gcc 2.95.2.1 on a
custom linux system (kernel 2.4.2, glibc 2.2.2) without
warnings.
Second I compile tested the code on Windows 2000 SP1
using VC++ 6.0 SP3 without warnings.
Attached are the sources.
apr_memory_system.[ch] core (using apr_stuff.h), includes
standard memory system.
apr_stuff.h hacked up include file to compile
without APR
I hope someone among you will fix up the include thingies :-)
More attachments:
apr_tracking_memory_system.[ch] example of a tracking
memory system implementation.
Sander
RE: APR shared memory requirements.
Posted by Sander Striker <st...@samba-tng.org>.
>> Also, a test program should be added as soon as this is
>> "buildable" so it's working can be verified as once committed
>
> Ah, ok, I was hoping that you guys could fill in the APR blanks that were
> in there (I'm not enough into APR to know all constant names and
> conventions you use).
Argh, I see your point now (I tried to compile the version I last sent
in and it didn't compile). I must have mixed up two versions in the
process (don't you hate it when you don't have cvs available on
occassion for whatever reason :-).
I'll sort this out and get back to you,
Sander
RE: APR shared memory requirements.
Posted by Sander Striker <st...@samba-tng.org>.
>> Ok, lets discuss this, people, speak up so we can do this 'right'
>> in one go (and quickly too) ;-)
> I'd rather not rush into something we regret in 6 months...
Let me rephrase that: with more feedback (preferably with fears/
reservations) the bottlenecks can be identified more quickly. Like
I said, the main thing is to do it right.
> Not trying to be a damp squid, but can we have a fully fledged and working
> example before too long. I have some concerns that this stuff is dropping
> us into a mire of complication...
Please tell us your worst fears :-)
> Hopefully a full example will allay my fears as you guys keep
> telling us how easy this stuff is to write :)
Well, to put it simply, the 'memory system thing' is just an abstraction
layer. If you implement a memory system you have to provide a number of
functions specific to your memory system: malloc, realloc(optional),
free(optional, provided you have a reset and destroy), reset(optional,
provided you have a free) and destroy(optional, provided you have a
free). And another optional pre_destroy. The destroy function is only
allowed to free memory, nothing else (the reason for this is that it
could be skipped). If you need to close files or whatever, do it in
pre_destroy. Hmm, ok, I said I was going to put it simply... hmmm.
Oh well :-)
> Also, a test program should be added as soon as this is
> "buildable" so it's working can be verified as once committed
Ah, ok, I was hoping that you guys could fill in the APR blanks that were
in there (I'm not enough into APR to know all constant names and
conventions you use).
> we're into the multi-platform arena, but you knew that, right? :)
Yes, I know :) [guess why we are tracking apr development]
For the record, as far as I know I only used standard c stuff in the
memory system code, so this should be portable across all platforms.
Please correct me if I'm wrong.
> david
Sander
Re: APR shared memory requirements.
Posted by David Reid <dr...@jetnet.co.uk>.
> Ok, lets discuss this, people, speak up so we can do this 'right'
> in one go (and quickly too) ;-)
I'd rather not rush into something we regret in 6 months...
Not trying to be a damp squid, but can we have a fully fledged and working
example before too long. I have some concerns that this stuff is dropping
us into a mire of complication...
Hopefully a full example will allay my fears as you guys keep telling us how
easy this stuff is to write :)
Also, a test program should be added as soon as this is "buildable" so it's
working can be verified as once committed we're into the multi-platform
arena, but you knew that, right? :)
david
RE: APR shared memory requirements.
Posted by Sander Striker <st...@samba-tng.org>.
>>> in this way, you could pass in a shmem-SMS-parent allocator
>>> to apr_pool_create(), and it will create a shared memory
>>> pool that looks, to all intents and purposes, like an apr_pool_t.
>>>
>>> interested?
>>
>> This sounds very cool. Certainly I'm interested.
>
> great-stuff. continue on dev@apr.apache.org? have some
> ideas on how to proceed on devel of an apr_memsys_shmem.
Ok, lets discuss this, people, speak up so we can do this 'right'
in one go (and quickly too) ;-)
> luke
>
> p.s. please please please can apr_pool_join() be dropped? :)
Indeed, when/if switching to mem_sys, this won't really be needed
anymore, just make sure to alloc from the same parent mem sys.
Also, this is very hard to incorporate in the concept/implementation
of memory systems :-)
Sander
Re: APR shared memory requirements.
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> > in this way, you could pass in a shmem-SMS-parent allocator
> > to apr_pool_create(), and it will create a shared memory
> > pool that looks, to all intents and purposes, like an apr_pool_t.
> >
> > interested?
>
> This sounds very cool. Certainly I'm interested.
great-stuff. continue on dev@apr.apache.org? have some
ideas on how to proceed on devel of an apr_memsys_shmem.
luke
p.s. please please please can apr_pool_join() be dropped? :)
Re: APR shared memory requirements.
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> > in this way, you could pass in a shmem-SMS-parent allocator
> > to apr_pool_create(), and it will create a shared memory
> > pool that looks, to all intents and purposes, like an apr_pool_t.
> >
> > interested?
>
> This sounds very cool. Certainly I'm interested.
great-stuff. continue on dev@apr.apache.org? have some
ideas on how to proceed on devel of an apr_memsys_shmem.
luke
p.s. please please please can apr_pool_join() be dropped? :)
Re: APR shared memory requirements.
Posted by Ben Laurie <be...@algroup.co.uk>.
Luke Kenneth Casson Leighton wrote:
>
> On Tue, May 01, 2001 at 08:49:43AM -0700, rbb@covalent.net wrote:
> >
> > Most people have realized that APR's shared memory support isn't good
> > enough to support Apache, or in reality most other applications. We had
> > this discussion during the hack-a-thon, and we came up with a small list
> > of requirements for APR's new shared memory implementation. Here are the
> > notes:
> >
> > 1) malloc-like implementation
> > 2) Anonymous and Key based shared memory support
> > 3) Def-ref macros (these must use double indirection)
> > 4) Reference counting
> > 5) Cleanups that use the pool implementation
>
> sander, elrond and i have written up a stackable memory system.
>
> we were waiting for an opportunity to present it to you [apr]
> such that it would be received.
>
> the stackable memory system basically allows one memory-allocation
> system to allocate memory from another.
>
> [not like the pool system, which is just a means to allocate
> memory from the system library (malloc/free), and to associate
> cleanup routines with it]
>
> there is nothing to stop you, or anyone, from writing a
> shared memory library that conforms to the SMS api.
>
> there is nothing to stop anyone from modifying apr_pool* to
> conform to the SMS api.
>
> in this way, you could pass in a shmem-SMS-parent allocator
> to apr_pool_create(), and it will create a shared memory
> pool that looks, to all intents and purposes, like an apr_pool_t.
>
> interested?
This sounds very cool. Certainly I'm interested.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: APR shared memory requirements.
Posted by Ben Laurie <be...@algroup.co.uk>.
Luke Kenneth Casson Leighton wrote:
>
> On Tue, May 01, 2001 at 08:49:43AM -0700, rbb@covalent.net wrote:
> >
> > Most people have realized that APR's shared memory support isn't good
> > enough to support Apache, or in reality most other applications. We had
> > this discussion during the hack-a-thon, and we came up with a small list
> > of requirements for APR's new shared memory implementation. Here are the
> > notes:
> >
> > 1) malloc-like implementation
> > 2) Anonymous and Key based shared memory support
> > 3) Def-ref macros (these must use double indirection)
> > 4) Reference counting
> > 5) Cleanups that use the pool implementation
>
> sander, elrond and i have written up a stackable memory system.
>
> we were waiting for an opportunity to present it to you [apr]
> such that it would be received.
>
> the stackable memory system basically allows one memory-allocation
> system to allocate memory from another.
>
> [not like the pool system, which is just a means to allocate
> memory from the system library (malloc/free), and to associate
> cleanup routines with it]
>
> there is nothing to stop you, or anyone, from writing a
> shared memory library that conforms to the SMS api.
>
> there is nothing to stop anyone from modifying apr_pool* to
> conform to the SMS api.
>
> in this way, you could pass in a shmem-SMS-parent allocator
> to apr_pool_create(), and it will create a shared memory
> pool that looks, to all intents and purposes, like an apr_pool_t.
>
> interested?
This sounds very cool. Certainly I'm interested.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: APR shared memory requirements.
Posted by rb...@covalent.net.
On Wed, 2 May 2001, Luke Kenneth Casson Leighton wrote:
> On Tue, May 01, 2001 at 08:49:43AM -0700, rbb@covalent.net wrote:
> >
> > Most people have realized that APR's shared memory support isn't good
> > enough to support Apache, or in reality most other applications. We had
> > this discussion during the hack-a-thon, and we came up with a small list
> > of requirements for APR's new shared memory implementation. Here are the
> > notes:
> >
> > 1) malloc-like implementation
> > 2) Anonymous and Key based shared memory support
> > 3) Def-ref macros (these must use double indirection)
> > 4) Reference counting
> > 5) Cleanups that use the pool implementation
>
> sander, elrond and i have written up a stackable memory system.
>
> we were waiting for an opportunity to present it to you [apr]
> such that it would be received.
>
>
> the stackable memory system basically allows one memory-allocation
> system to allocate memory from another.
>
> [not like the pool system, which is just a means to allocate
> memory from the system library (malloc/free), and to associate
> cleanup routines with it]
>
> there is nothing to stop you, or anyone, from writing a
> shared memory library that conforms to the SMS api.
>
> there is nothing to stop anyone from modifying apr_pool* to
> conform to the SMS api.
>
> in this way, you could pass in a shmem-SMS-parent allocator
> to apr_pool_create(), and it will create a shared memory
> pool that looks, to all intents and purposes, like an apr_pool_t.
>
> interested?
Oh yeah! Could you point the APR developers to where this is implemented,
or post a patch? I think this would be REALLY cool to get into APR,
because it would solve most, if not all, of our memory handling needs.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: APR shared memory requirements.
Posted by rb...@covalent.net.
On Wed, 2 May 2001, Luke Kenneth Casson Leighton wrote:
> On Tue, May 01, 2001 at 08:49:43AM -0700, rbb@covalent.net wrote:
> >
> > Most people have realized that APR's shared memory support isn't good
> > enough to support Apache, or in reality most other applications. We had
> > this discussion during the hack-a-thon, and we came up with a small list
> > of requirements for APR's new shared memory implementation. Here are the
> > notes:
> >
> > 1) malloc-like implementation
> > 2) Anonymous and Key based shared memory support
> > 3) Def-ref macros (these must use double indirection)
> > 4) Reference counting
> > 5) Cleanups that use the pool implementation
>
> sander, elrond and i have written up a stackable memory system.
>
> we were waiting for an opportunity to present it to you [apr]
> such that it would be received.
>
>
> the stackable memory system basically allows one memory-allocation
> system to allocate memory from another.
>
> [not like the pool system, which is just a means to allocate
> memory from the system library (malloc/free), and to associate
> cleanup routines with it]
>
> there is nothing to stop you, or anyone, from writing a
> shared memory library that conforms to the SMS api.
>
> there is nothing to stop anyone from modifying apr_pool* to
> conform to the SMS api.
>
> in this way, you could pass in a shmem-SMS-parent allocator
> to apr_pool_create(), and it will create a shared memory
> pool that looks, to all intents and purposes, like an apr_pool_t.
>
> interested?
Oh yeah! Could you point the APR developers to where this is implemented,
or post a patch? I think this would be REALLY cool to get into APR,
because it would solve most, if not all, of our memory handling needs.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: APR shared memory requirements.
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Tue, May 01, 2001 at 08:49:43AM -0700, rbb@covalent.net wrote:
>
> Most people have realized that APR's shared memory support isn't good
> enough to support Apache, or in reality most other applications. We had
> this discussion during the hack-a-thon, and we came up with a small list
> of requirements for APR's new shared memory implementation. Here are the
> notes:
>
> 1) malloc-like implementation
> 2) Anonymous and Key based shared memory support
> 3) Def-ref macros (these must use double indirection)
> 4) Reference counting
> 5) Cleanups that use the pool implementation
sander, elrond and i have written up a stackable memory system.
we were waiting for an opportunity to present it to you [apr]
such that it would be received.
the stackable memory system basically allows one memory-allocation
system to allocate memory from another.
[not like the pool system, which is just a means to allocate
memory from the system library (malloc/free), and to associate
cleanup routines with it]
there is nothing to stop you, or anyone, from writing a
shared memory library that conforms to the SMS api.
there is nothing to stop anyone from modifying apr_pool* to
conform to the SMS api.
in this way, you could pass in a shmem-SMS-parent allocator
to apr_pool_create(), and it will create a shared memory
pool that looks, to all intents and purposes, like an apr_pool_t.
interested?
luke
Re: APR shared memory requirements.
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Tue, May 01, 2001 at 08:49:43AM -0700, rbb@covalent.net wrote:
>
> Most people have realized that APR's shared memory support isn't good
> enough to support Apache, or in reality most other applications. We had
> this discussion during the hack-a-thon, and we came up with a small list
> of requirements for APR's new shared memory implementation. Here are the
> notes:
>
> 1) malloc-like implementation
> 2) Anonymous and Key based shared memory support
> 3) Def-ref macros (these must use double indirection)
> 4) Reference counting
> 5) Cleanups that use the pool implementation
sander, elrond and i have written up a stackable memory system.
we were waiting for an opportunity to present it to you [apr]
such that it would be received.
the stackable memory system basically allows one memory-allocation
system to allocate memory from another.
[not like the pool system, which is just a means to allocate
memory from the system library (malloc/free), and to associate
cleanup routines with it]
there is nothing to stop you, or anyone, from writing a
shared memory library that conforms to the SMS api.
there is nothing to stop anyone from modifying apr_pool* to
conform to the SMS api.
in this way, you could pass in a shmem-SMS-parent allocator
to apr_pool_create(), and it will create a shared memory
pool that looks, to all intents and purposes, like an apr_pool_t.
interested?
luke