On Sunday, 30 August 2015 at 21:52:37 UTC, ZombineDev wrote:
On Sunday, 30 August 2015 at 20:44:17 UTC, ponce wrote:
In the case the destructor isn't called by the GC, the call
must succeed.
GC.malloc(1) fits the bill but it's a waste of time and memory
indeed. GC.free(<invalid-adress>) would fail in both cases if
I understand correctly.
As you can see from the output
(http://dpaste.dzfl.pl/aa004554034a), when
GC.free(cast(void*)1) is called in main() it doesn't throw. It
only throws in the destructor of A, because a GC collection is
taking place.
If you look at the implementation, it is more or less
guaranteed that:
a) GC.free() during collection -> InvalidMemoryOperationError
[1]
b) GC.free() with invalid pointer -> no-op [2]
Cool thing.
Perhaps as a getter like GC.isRunning()?
Yeah, that's what I had in mind. But maybe it also makes sense
to provide a way to take the GC lock? Of course, such method
should definitely be marked as @system.
[1]:
https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L879
[2]:
https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L888
I'm not sure there is even a need for synchronization since other
threads that wan't to allocate try to take the GC lock while the
GC-hijacked thread calls destructors.
And if the destructor isn't called by the GC, I don't see a
problem either.tre
