On Saturday, 12 September 2015 at 00:31:27 UTC, Andrei
Alexandrescu wrote:
On 09/11/2015 07:46 PM, bitwise wrote:
[...]
Say you have a container that uses its own allocator inside,
yet offers the user to store objects with indirections that use
the GC. Then indeed the container would need to call addRange
and removeRange on its own internal structures.
This sounds like the default setup I'll be using. The containers
will use a Mallocator by default, so I will have to add the
ranges when the contained type is found to have indirections.
If, on the contrary, the container imposes that its own held
objects use the container's allocator as well (a rare but not
implausible design), it wouldn't need to do that.
I don't understand exactly what you mean, but here is a more
verbose version of my concern:
Lets say someone's allocator calls GC.addRange on the memory it
allocates before a container gets it. The container would call
GC.addRange when it gets it, but then call GC.removeRange before
calling allocator.deallocate(). The allocator which think's the
block has already been registered with the GC could possibly
reuse it, thinking it's registered with the GC already....but
that allocator may pass the memory to a container which chooses
not to call GC.addRange, because it thinks it's using an
allocator that does that for it. That second container may now
store types with indirections, which would be unreachable, and
get freed, and......chaos.
I suppose that as a general rule, a container could always add
ranges it gets from an allocator to the GC, which would prevent
the above problem...but only for containers that abide by the
rule. It sounds like you're saying that although it may not be
needed sometimes, that no harm would be done.
I think a better solution though would be for the GC to have
something like GC.hasRange(). The container could check the state
of the memory it receives and take appropriate action. I don't
see anything in the current GC docs which would allow you to tell
if a range had already been added to the GC.
Bit
