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.
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/10/23 Schwab,Wilhelm K <[hidden email]>:
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
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




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko
Sent: Friday, October 23, 2009 1:09 AM
To: [hidden email]
Subject: Re: [Pharo-project] Finalization question

2009/10/23 Schwab,Wilhelm K <[hidden email]>:
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/10/23 Schwab,Wilhelm K <[hidden email]>:
> 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.



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko
Sent: Friday, October 23, 2009 1:49 AM
To: [hidden email]
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.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project