apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Re: Adding first/next block to apr_rmm
Date Sat, 15 Nov 2008 06:46:37 GMT
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)

Mime
View raw message