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)
