std.allocator ready for some abuse

[bitwise via Digitalmars-d]

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