draft proposal for ref counting in D

[Walter Bright]

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.

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.