[Pharo-project] Finalization question
Hello all, I have started to port some of my code that relies on Dolphin's finalization. The idea is that one sends #beFinalizable to the object requiring finalization. Dolphin sets a flag on the object (in its header??) that the vm later notices.
2009/10/23 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Hello all,
I have started to port some of my code that relies on Dolphin's finalization. Â The idea is that one sends #beFinalizable to the object requiring finalization. Â Dolphin sets a flag on the object (in its header??) that the vm later notices.
a rough analogy is something like that: Object>>beFinalizable "A shallow copy of the receiver will receive a #finalize message, once the receiver become garbage" WeakRegistry default add: self
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Sig, Thanks for the quick reply. I finished my thought, which might help you figure out what I'm missing. As an aside, I would like to identify and finalize the Outlook hotkey that launched that email before I was ready - I've never seen Outlook do *anything* that fast. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Friday, October 23, 2009 1:09 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Finalization question 2009/10/23 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Hello all,
I have started to port some of my code that relies on Dolphin's finalization. Â The idea is that one sends #beFinalizable to the object requiring finalization. Â Dolphin sets a flag on the object (in its header??) that the vm later notices.
a rough analogy is something like that: Object>>beFinalizable "A shallow copy of the receiver will receive a #finalize message, once the receiver become garbage" WeakRegistry default add: self
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Sorry for the extra message. Outlook - need I say more? Hello all, I have started to port some of my code that relies on Dolphin's finalization. The idea is that one sends #beFinalizable to the object requiring finalization. Dolphin sets a flag on the object (in its header??) that the vm later notices. The end result is the object in question receives #finalize and cleans up its own mess; it can also "cheat death" but I doubt I have need for that level of control. My question is that the Squeak/Pharo design appears to be built on ObjetFinalizer instances that are associated with finalizable objects, each recording what to do when an object expires. If that's true, then I'm wondering why objects understand #finalize. That seems to conflict with #toFinalize:send:to:with:, which looks like it expects just enough information to do the cleanup for the expired object. Any idea what I might be missing here or pointers to required reading? I found something from 2003 (Squeak 3.7) which might be out of date, or maybe I'm just working too late :) Bill
2009/10/23 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Sorry for the extra message. Â Outlook - need I say more?
Hello all,
I have started to port some of my code that relies on Dolphin's finalization. Â The idea is that one sends #beFinalizable to the object requiring finalization. Â Dolphin sets a flag on the object (in its header??) that the vm later notices. Â The end result is the object in question receives #finalize and cleans up its own mess; it can also "cheat death" but I doubt I have need for that level of control.
My question is that the Squeak/Pharo design appears to be built on ObjetFinalizer instances that are associated with finalizable objects, each recording what to do when an object expires. Â If that's true, then I'm wondering why objects understand #finalize. Â That seems to conflict with #toFinalize:send:to:with:, which looks like it expects just enough information to do the cleanup for the expired object.
you can use #add:executor: and provide a custom executor for object. An ObjectFinalizer just a generic class provided for convenience. Anyways, all of this stuff ends up in WeakRegistry, so its a question of personal taste, what to use. Or, if you think you are hardcore, you can write own class which provides finalizatin services. Then you can add it to: WeakArray addWeakDependent: yourStuff. And at each GC cycle, when finalization process will awake, your object will receive #finalizeValues mesasge, where you free to choose what to finalize and how.
Any idea what I might be missing here or pointers to required reading? Â I found something from 2003 (Squeak 3.7) which might be out of date, or maybe I'm just working too late :)
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Sig, I think I am starting to understand. One thing though: WeakRegistry is a singleton customized to be part of the finalizer?? Not sure I like that. The name is too generic for the task. If I am indeed following, it sounds as though what Dolphin does with a flag on the expired object, Pharo does using a shallow copy of or other executor for the expired object. Does that sound like a reasonable paraphrasing? I am not sure which design I prefer, but I should be able to fake up an appropriate #beUnfinalizable to make my code happy on Pharo. Thanks!! Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Friday, October 23, 2009 1:49 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Finalization question a rough analogy is something like that: Object>>beFinalizable "A shallow copy of the receiver will receive a #finalize message, once the receiver become garbage" WeakRegistry default add: self you can use #add:executor: and provide a custom executor for object. An ObjectFinalizer just a generic class provided for convenience. Anyways, all of this stuff ends up in WeakRegistry, so its a question of personal taste, what to use. Or, if you think you are hardcore, you can write own class which provides finalizatin services. Then you can add it to: WeakArray addWeakDependent: yourStuff. And at each GC cycle, when finalization process will awake, your object will receive #finalizeValues mesasge, where you free to choose what to finalize and how.
participants (2)
-
Igor Stasenko -
Schwab,Wilhelm K