On 6/30/2013 4:35 PM, Michel Fortin wrote:
> Le 30-juin-2013 à 18:11, Walter Bright a écrit :
>
>> 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.
>
> ... checked and decremented, and if it reaches zero in the thread the GC is
currently running then it doesn't have to delete the object as, in theory, it
should be destructed as part of the same run. Ok, I get it now.
>
> You should add a requirement that the reference counter be atomic because the
GC can run in any thread and you still need to decrement counters of referenced
objects in destructor.
I very much want to avoid requiring atomic counts - it's a major performance
penalty. Note that if the GC is reaping a cycle, nobody else is referencing the
object, so this should not be an issue.
>
> Honestly, I think it'd be much easier if the runtime provided its own base
object you could use for reference counting with the GC to collect cycles. The
provided implementation could rely on internal details of the GC since both
would be part of druntime. There isn't much room for alternate implementations
when the GC is involved anyway.
>
