Issue #5494 has been updated by Nobuyoshi Nakada.

Status changed from Open to Rejected

Even if the object has not been freed, other objects referred by the
object might be freed already.  It has to sort topologically the
directed graph, even for simple cases.  Not only this would be quite
expensive, cyclic references cannot sort.

----------------------------------------
Feature #5494: Proposal: Improved Finalizer Semantics  
http://redmine.ruby-lang.org/issues/5494

Author: Kurt  Stephens
Status: Rejected
Priority: Normal
Assignee: 
Category: 
Target version: 2.0


Proposal: Improved Finalizer Semantics:

ObjectSpace.define_finalizer(object, proc):
** proc should have a single parameter, the object to be finalized, not its id.

When an object with a finalizer is no longer referenced (sweepable):
* The object is reconsidered to be REFERENCED until next GC.
* It's finalizer proc(s) are called, only once, with the object as the sole argument.
* Subsequently, the finalizer procs are removed from the object.
* The object's memory will *NOT* be reclaimed yet, nor will its C free_proc be called, 
  since calling the finalizer proc effectively creates new (temporary) references to the object.
* If the finalizer did *NOT* create any additonal, long-term references to the object, 
  the object's memory and low-level C resources will be reclaimed in the next GC.

This is a simpler protocol: 

* It removes the need for _id2ref in the finalizer procs.
* Prevents other complications: such as GC being reinvoked within a finalizer.
* Finalizers are invoked with the same "urgency" as before.

The downside:

* Objects with finalizers actually live for more than one GC cycle, if they are unreferenced.
* This is probably acceptable since the resources the finalizers "clean-up"
(eg.: file descriptors in a File object) are generally more scarce than the objects holding them.






-- 
http://redmine.ruby-lang.org