From: MikkelFJ Date: 2001-11-29T06:53:28+09:00 Subject: [ruby-talk:26841] Re: Ref Counting (was KDE or GNOME curiosity question...) "mark hahn" wrote in message news:004801c17850$95ec4250$2a8bb8d0@web4... > For example, only references to a File object that rely on the object being > opened or closed need to be considered when deciding whether the file can be > closed at any particular point in time. Most of these issues can be handled directly by subscribe / unscribe semantics of an object. You may keep a link to a subscriber for events, but you can also choose to only maintain a refcount. In any case you perform cleanup when the number of subscriptions hits zero. The object may then be finalized at a later point - or reused in an object pool. This requires no changes, but a general subscriptions Mixin could be written - one for refcount and one with event notifications. Very trivial. related: Microfts GC for .NET has some internal confimation logic in the GC. An object is finalized before memory is reclaimed. During this process the object is parked in a pseudo state where it is neither allocated nor dealloced. The object can in the finalization choose to be revived and it can modify the heap by allocating objects requring rescans. I don't recall the details - its a bit complicated but not that complicated. There is an article at MS developer journal on the issue. However, their solution does not handle the problem of early finalization. You either need compiler scope control or som manual unscribe method. You could combine finalize with unsubcribe such that a user object will automatically calls unsubscribe on a resource if its owner failed to do so. part 1 http://msdn.microsoft.com/msdnmag/issues/1100/GCI/GCI.asp part 2 http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/GCI2.asp MikkelFJ