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?
