Steven Schveighoffer wrote:
On Jun 30, 2013, at 6:11 PM, Walter Bright wrote:
>
> On 6/30/2013 3:05 PM, Michel Fortin wrote:
>> Le 2013-06-30 à 16:32, Walter Bright a écrit :
>>
>>> Amended as:
>>>
>>> 6. If a class or struct contains RC fields, calls to Release() for those
fields will
>>> be added to the destructor, and a destructor will be created if one doesn't
exist already.
>>> Release() implementations should take care to not destroy objects that are
already destroyed,
>>> which can happen if the objects are allocated on the GC heap and the GC
removes a cycle of
>>> refcounted objects.
>> Good advice. But... how do you implement that? For one thing, I doubt
there's an API in the GC you can query for deleted objects, and if there was
it'd be inefficient to call it for every call to Release. And also, will a
virtual call to a function of a destroyed object work in the first place? It all
seems quite fragile to me.
>>
>
> The GC doesn't actually delete anything while it is doing a collection cycle.
So the refcount could simply be checked.
AFAIK, this isn't a requirement of the GC. May want to add it. I have bad
experiences with trying to second guess the GC and when it actually kills the
object.
Note, if this is the case, then inc/dec refcount cannot depend on vtable, since
that is zeroed. I'm wondering if the GC shouldn't set the RC to size_t.max when
destructing, or even just +1 it, to ensure the ref count destructor doesn't
accidentally free it before the reaper does.
-Steve
