Adding first/next block to apr_rmm

[Mladen Turk <mt...@apache.org>]

Hi,

Here is a patch that adds two new functions to rmm for obtaining
the first and next allocated memory blocks.
This is useful in searching or maintaining the entire rmm and skips
the need for allocating the array of allocated blocks.

Well, the code is self explanatory I hope.
Any objections for commit that to the trunk?

Regards
-- 
^(TM)

Re: Adding first/next block to apr_rmm

[Mladen Turk <mt...@apache.org>]

William A. Rowe, Jr. wrote:
>>> Howso?  It seems good to add these for better allocators within the rmm
>>> api itself, but is this the sort of introspection we expect people to do
>>> from outside of our implementation?
>>>
>> It would be if the apr_rmm structures were not private.
>> If one wishes to loop trough the allocated rmm blocks
>> the only way is to maintain an external array of allocated
>> blocks. However this concept fails if used for what is
>> mostly meant (attached to the shared memory block) to be used.
> 
> Well, my question is what are you trying to get at?  Clearly you want to
> expose the internals, but I'm altogether unclear of how/why a developer
> needs that data... it implies our rmm implementation is missing some key
> feature (not "inspect allocations" ... but something beyond that) which
> would make it more useful.
> 
> When folks say "I need this to be transparent" I usually read it as
> "you forgot to implement..."
> 
> 

The typical application is shared memory.
One process allocates some data, and this needs to be evaluated by
the another process. The second process doesn't know the actual
offsets so it need to get them somehow to be able to recreate
allocated shared memory chunks (some variable sized records).

What I'm currently doing, is allocating two shared memories
one for rmm and another for storing offsets. The attached process
then reads the offset table and uses them as offsets to the
real (data) rmm.
To much overhead for such a simple thing, cause data is already
present in the rmm (only hidden).

Regards
-- 
^(TM)

Re: Adding first/next block to apr_rmm

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Mladen Turk wrote:
> William A. Rowe, Jr. wrote:
>>>
>>> Well, the code is self explanatory I hope.
>>> Any objections for commit that to the trunk?
>>
>> Howso?  It seems good to add these for better allocators within the rmm
>> api itself, but is this the sort of introspection we expect people to do
>> from outside of our implementation?
>>
> 
> It would be if the apr_rmm structures were not private.
> If one wishes to loop trough the allocated rmm blocks
> the only way is to maintain an external array of allocated
> blocks. However this concept fails if used for what is
> mostly meant (attached to the shared memory block) to be used.

Well, my question is what are you trying to get at?  Clearly you want to
expose the internals, but I'm altogether unclear of how/why a developer
needs that data... it implies our rmm implementation is missing some key
feature (not "inspect allocations" ... but something beyond that) which
would make it more useful.

When folks say "I need this to be transparent" I usually read it as
"you forgot to implement..."

Re: Adding first/next block to apr_rmm

[Mladen Turk <mt...@apache.org>]

William A. Rowe, Jr. wrote:
>>
>> Well, the code is self explanatory I hope.
>> Any objections for commit that to the trunk?
> 
> Howso?  It seems good to add these for better allocators within the rmm
> api itself, but is this the sort of introspection we expect people to do
> from outside of our implementation?
> 

It would be if the apr_rmm structures were not private.
If one wishes to loop trough the allocated rmm blocks
the only way is to maintain an external array of allocated
blocks. However this concept fails if used for what is
mostly meant (attached to the shared memory block) to be used.

Regards
-- 
^(TM)

Re: Adding first/next block to apr_rmm

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Mladen Turk wrote:
> Hi,
> 
> Here is a patch that adds two new functions to rmm for obtaining
> the first and next allocated memory blocks.
> This is useful in searching or maintaining the entire rmm and skips
> the need for allocating the array of allocated blocks.
> 
> Well, the code is self explanatory I hope.
> Any objections for commit that to the trunk?

Howso?  It seems good to add these for better allocators within the rmm
api itself, but is this the sort of introspection we expect people to do
from outside of our implementation?

Re: Adding first/next block to apr_rmm

[Jeff Trawick <tr...@gmail.com>]

On 11/12/08, Mladen Turk <mt...@apache.org> wrote:
> Hi,
>
> Here is a patch that adds two new functions to rmm for obtaining
> the first and next allocated memory blocks.

First line of comment for next fn needs to be tweaked (!first).
> This is useful in searching or maintaining the entire rmm and skips
> the need for allocating the array of allocated blocks.
>
> Well, the code is self explanatory I hope.
> Any objections for commit that to the trunk?
>
> Regards
> --
> ^(TM)
>


-- 
Born in Roswell... married an alien...