GC behavior and Allocators

[Chris Cain via Digitalmars-d]

On Friday, 4 July 2014 at 10:36:03 UTC, safety0ff wrote:
> I just thought a little more about this and you will always 
> have a race.
>
> Consider this code:
> auto a = malloc(aSize);
> GC.addRange(a, aSize);
> auto b = realloc(a, aSize * 2);
>
> If realloc moves the data (a != b) and the GC runs before you 
> can fix up the ranges you can have invalid access during 
> collection.

http://dlang.org/phobos/core_memory.html#.GC.enable

If GC.enable and GC.disable truly disallowed GC running (or 
alternative `GC.hard_disable`/`GC.hard_enable` existed that 
guaranteed such) then you could use that to make sure that the GC 
didn't collect in the middle of a pair of those calls.

On Friday, 4 July 2014 at 11:54:07 UTC, Kagamin wrote:
> If you reallocate doubling the size, it's likely such reallocs 
> always move, so they should be equivalent to malloc+free, so 
> your code can be
>
> mem2 = alloc(sz*2);
> mem2[] = mem1[];
> addRange(mem2);
> removeRange(mem1);
> free(mem1);
>
> if not, you need to lock the GC so that it won't interfere 
> during realloc.

Is there a way to lock the GC currently?