On Sun, 28 Apr 2013 16:25:06 -0700, Vladimir Panteleev
<[email protected]> wrote:
On Sunday, 28 April 2013 at 14:44:32 UTC, Steven Schveighoffer wrote:
No, destructors are called along with deallocation. At the moment, the
GC mutex is held while the collection is in progress, so it's not
possible that a deallocated block could be reallocated before a dtor
that references that block is called.
Right, so it makes no difference in practice.
What I meant was that IIRC early versions of the GC used to rebuild
internal free lists, and clobber freed data, in-loop with calling
destructors. Thus, when referencing something in a destructor, sometimes
you'd get the same object (not yet finalized), and sometimes you'd get
garbage. Now you get a finalized object instead of garbage.
This was not a "bug," probably (can't be definite on it, since I'm unaware
of how the GC used to work).
But that is an implementation detail. There is no requirement for the
GC to behave that way.
I don't disagree with you, but do we have a spec for GCs?
AFAIK there is no spec, it's all based on the compiler implementation.
For all I know, the GC on GDC or LDC may have a different API.
I'd think preserving memory safety, even in a destructor, would be
pretty important for a GC design.
I wouldn't expect it. code is code, not sure how you can guarantee memory
safety in a dtor.
In addition, there is no requirement for the GC to run in a specific
thread, so if a destroyed object references a non-destroyed object,
it's possible some thread is using the non-destroyed object while the
dtor is using it in another thread, even if the object was only ever
accessed from one thread!
Sorry, not following. What's the problem? How is this related?
Like an unlocked reference counter, let's say. It's only ever used in one
thread. But then an object with a reference becomes garbage. Another
thread then runs the garbage collector, enabling race conditions that
would not normally be possible.
-Steve
