Well, there's a concept of a _weak_ reference. I don't know whether it exists in Rust but I can't imaigne a modern reference counting system without support for it.
A weak reference does not prevent the object from being deallocated, but the system guarantees that when the object is deallocated, all weak references to it will be nullified.
This is what makes deallocating objects in a refcounting system potentially arbitrarily expensive.
> A weak reference does not prevent the object from being deallocated, but the system guarantees that when the object is deallocated, all weak references to it will be nullified.
> This is what makes deallocating objects in a refcounting system potentially arbitrarily expensive.
Depends how you implement weakrefs. In Rust, when you upgrade a weakref it checks if there are outstanding strong references, and if there are not the control block is considered invalid and the upgrade fails.
There is no need to touch any of the weakrefs at any point.
And unlike languages like Python, Rust does not have weakref finalizers either.
Deallocation is still arbitrarily expensive in general, as the entire subtree will get deallocated recursively, but that has nothing to do with refcounting.
The way it works is, in order to use it you try to upgrade it to a normal Refcounted pointer. Since it is a weak reference, this upgrade may of course fail and in that case return None (in place of a null pointer). When this upgraded pointer dies (either goes out of scope or is manually downgraded) the refcount will again be updated.
A weak reference does not prevent the object from being deallocated, but the system guarantees that when the object is deallocated, all weak references to it will be nullified.
This is what makes deallocating objects in a refcounting system potentially arbitrarily expensive.