GC: memory collected but destructors not called
Steven Schveighoffer via Digitalmars-d
digitalmars-d at puremagic.com
Tue Nov 11 12:41:29 PST 2014
On 11/11/14 2:46 PM, Rainer Schuetze wrote:
>
>
> On 10.11.2014 15:19, Steven Schveighoffer wrote:
>>
>> Now, imagine you wanted to put this on the GC heap, and the GC would
>> call struct dtors. And let's say the program is multi-threaded. First,
>> the memory referred to by t isn't guaranteed to be alive, it could have
>> already been finalized and freed. Second, the thread that calls the
>> destructor may not be the thread that owns t. This means that two
>> threads could potentially be calling t.inc() or t.dec() at the same
>> time, leading to race conditions.
>
> So, would you object to actually call the destructor for GC collected
> structs? I don't think that threading problems in the implmentation of
> the destructor should prohibit this.
>
> The reference count in your example also doesn't work for heap allocated
> structs that are never collected or for structs inside classes.
>
I think in general, it's a problem of the expectation of where structs
will live. It's obvious we know classes will be on the heap, so we can
write those dtors accordingly. Most struct dtors are written for when
the struct is on the stack.
The way around this is to have 2 functions for destruction -- as Tango
does. One is called during synchronous destruction (i.e. when a struct
goes out of scope, or when destroy is called), and the other is called
during both synchronous and asynchronous destruction (when the GC is
collecting).
But even that solution does not allow the struct that I wrote to
properly deal with the GC. If the struct has a reference to GC memory,
it CANNOT access it during GC destruction to decrement the count, as the
memory may be gone.
It is why all the claims that we can accomplish what we want with
reference counting backed by the GC all never seem to satisfy my doubts.
> The pull request is almost ready to be merged, please chime in:
> https://github.com/D-Programming-Language/druntime/pull/864
At this point, I am not super-concerned about this. I cannot think of
any bullet-proof way to ensure that struct dtors for structs that were
meant only for stack variables can be called correctly from the GC. This
pull doesn't change that, and it does have some nice new features that
we do need for other reasons.
In other words, putting a struct in the GC heap that was written to be
scope-destroyed is an error before and after this pull. Before the pull,
the dtor doesn't run, which is wrong, and after the pull the dtor may
cause race issues, which is wrong. So either way, it's wrong :)
I also am strapped for free cycles to review such PRs. I trust you guys
know what you are doing :)
-Steve
More information about the Digitalmars-d
mailing list