Multiple finalizers per single object
Locked
Multiple finalizers per single object
 
|
Hello,
i'd like to raise this subject once more, because i don't like it (or don't understand?). In all scenarios, where i met the need to use finalization, a single finalizer is sufficient. Moreover, there is always a single object who controls a weak reference, and it never leaks it out, to prevent the case, when some other object may obtain a strong reference on it, making it permanently held in object memory. Multiple different finalizers for single object, from design point of view, means that you having two different, not related frameworks, which using same object, and want to do something when it dies. A scenario, where its possible and userful, still don't comes into my mind. In contrary, whenever i see a use of finalizers, its in most cases about graceful control over external resource, such as: - file - socket - external memory and i really don't see how multiple finalizers per single resource could do any good. Suppose one finalizer closing a file handle, while another one flushing it buffer cache. Now, how you going to ensure, that one finalizer will execute first, before another one? And what if third framework comes into play and wants to add another finalizer on top of that, which should do something in the middle between flushing a cache and closing file handle? From the above, the only conclusion can be made: use a single finalizer, and put all logic & operation ordering into it. And also, prevent leakage of object pointer (such as file handle) outside of your model, otherwise it may cause harm. That's why i think a current WeakRegistry model provoking bad design practices. I think a better behavior would be to raise an error, if something wants to register finalizer twice for a single object. -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Multiple finalizers per single object
|
|
I agree that multiple finalizers per object seems unnecessary and, as
you pointed out, potentially confusing, if not also conflicting. TSTTCPW seems appropriate in this case. On Thu, Sep 23, 2010 at 3:23 PM, Igor Stasenko <[hidden email]> wrote: > Hello, > > i'd like to raise this subject once more, because i don't like it (or > don't understand?). > > In all scenarios, where i met the need to use finalization, a single > finalizer is sufficient. > Moreover, there is always a single object who controls a weak > reference, and it never leaks it out, to prevent > the case, when some other object may obtain a strong reference on it, > making it permanently held in object memory. > > Multiple different finalizers for single object, from design point of > view, means that you having two different, not related frameworks, > which using same object, and want to do something when it dies. > A scenario, where its possible and userful, still don't comes into my mind. > In contrary, whenever i see a use of finalizers, its in most cases > about graceful control over external resource, such as: > - file > - socket > - external memory > > and i really don't see how multiple finalizers per single resource > could do any good. > > Suppose one finalizer closing a file handle, while another one > flushing it buffer cache. > Now, how you going to ensure, that one finalizer will execute first, > before another one? > And what if third framework comes into play and wants to add another > finalizer on top of that, which should do something in the middle > between flushing a cache and closing file handle? > > >From the above, the only conclusion can be made: use a single > finalizer, and put all logic & operation ordering into it. > And also, prevent leakage of object pointer (such as file handle) > outside of your model, otherwise it may cause harm. > > That's why i think a current WeakRegistry model provoking bad design practices. > I think a better behavior would be to raise an error, if something > wants to register finalizer twice for a single object. > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Multiple finalizers per single object
|
|
In reply to this post by Igor Stasenko
Sig,
No argument here. In fact, I'll raise you :) Weak collections in general, not just the finalizer registry, need to repair themselves in a thread-safe manner. http://thread.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/15001/focus=15172 http://article.gmane.org/gmane.comp.lang.smalltalk.sapphire.devel/14732 * Weak collections are of reduced value if they hang onto empty slots. * Enter a high-priority thread to strip away such junk; the weaklings must now be threadsafe. * You and others come along wanting to do things like #at:ifAbsentPut: (ensuring one-off registration, etc.) and suddenly find that you are doing this via a thread-safe collection that can get this stuff right. Bill ________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Igor Stasenko [[hidden email]] Sent: Thursday, September 23, 2010 4:23 PM To: The general-purpose Squeak developers list; Pharo Development; Levente Uzonyi Subject: [Pharo-project] Multiple finalizers per single object Hello, i'd like to raise this subject once more, because i don't like it (or don't understand?). In all scenarios, where i met the need to use finalization, a single finalizer is sufficient. Moreover, there is always a single object who controls a weak reference, and it never leaks it out, to prevent the case, when some other object may obtain a strong reference on it, making it permanently held in object memory. Multiple different finalizers for single object, from design point of view, means that you having two different, not related frameworks, which using same object, and want to do something when it dies. A scenario, where its possible and userful, still don't comes into my mind. In contrary, whenever i see a use of finalizers, its in most cases about graceful control over external resource, such as: - file - socket - external memory and i really don't see how multiple finalizers per single resource could do any good. Suppose one finalizer closing a file handle, while another one flushing it buffer cache. Now, how you going to ensure, that one finalizer will execute first, before another one? And what if third framework comes into play and wants to add another finalizer on top of that, which should do something in the middle between flushing a cache and closing file handle? From the above, the only conclusion can be made: use a single finalizer, and put all logic & operation ordering into it. And also, prevent leakage of object pointer (such as file handle) outside of your model, otherwise it may cause harm. That's why i think a current WeakRegistry model provoking bad design practices. I think a better behavior would be to raise an error, if something wants to register finalizer twice for a single object. -- 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 |
Re: Multiple finalizers per single object
|
|
On 24 September 2010 00:04, Schwab,Wilhelm K <[hidden email]> wrote:
> Sig, > > No argument here. In fact, I'll raise you :) Weak collections in general, not just the finalizer registry, need to repair themselves in a thread-safe manner. > > http://thread.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/15001/focus=15172 > http://article.gmane.org/gmane.comp.lang.smalltalk.sapphire.devel/14732 > > * Weak collections are of reduced value if they hang onto empty slots. > * Enter a high-priority thread to strip away such junk; the weaklings must now be threadsafe. > * You and others come along wanting to do things like #at:ifAbsentPut: (ensuring one-off registration, etc.) and suddenly find that you are doing this via a thread-safe collection that can get this stuff right. > Bill, weak collections are thread-safe, if you using them correctly. :) All weaklings dying in thread-safe manner when GC sweeps garbage, and replaced by nils. This is an atomic operation, seen from language side and having no chance to be interrupted. > Bill > > > ________________________________________ > From: [hidden email] [[hidden email]] On Behalf Of Igor Stasenko [[hidden email]] > Sent: Thursday, September 23, 2010 4:23 PM > To: The general-purpose Squeak developers list; Pharo Development; Levente Uzonyi > Subject: [Pharo-project] Multiple finalizers per single object > > Hello, > > i'd like to raise this subject once more, because i don't like it (or > don't understand?). > > In all scenarios, where i met the need to use finalization, a single > finalizer is sufficient. > Moreover, there is always a single object who controls a weak > reference, and it never leaks it out, to prevent > the case, when some other object may obtain a strong reference on it, > making it permanently held in object memory. > > Multiple different finalizers for single object, from design point of > view, means that you having two different, not related frameworks, > which using same object, and want to do something when it dies. > A scenario, where its possible and userful, still don't comes into my mind. > In contrary, whenever i see a use of finalizers, its in most cases > about graceful control over external resource, such as: > - file > - socket > - external memory > > and i really don't see how multiple finalizers per single resource > could do any good. > > Suppose one finalizer closing a file handle, while another one > flushing it buffer cache. > Now, how you going to ensure, that one finalizer will execute first, > before another one? > And what if third framework comes into play and wants to add another > finalizer on top of that, which should do something in the middle > between flushing a cache and closing file handle? > > From the above, the only conclusion can be made: use a single > finalizer, and put all logic & operation ordering into it. > And also, prevent leakage of object pointer (such as file handle) > outside of your model, otherwise it may cause harm. > > That's why i think a current WeakRegistry model provoking bad design practices. > I think a better behavior would be to raise an error, if something > wants to register finalizer twice for a single object. > > > -- > 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 > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Multiple finalizers per single object
|
|
In reply to this post by Chris Muller-3
I sort of disagree, in that it's neat to have a way for objects to be notified when other objects die, without that object necessarily having to know about all objects that may be interested in its death.
(Like, in Leventes case which triggered their creation in the first place, objects which are weakly registered to one or more announcers) I don't really see the benefit in constraining an existing, flexible mechanic to only cover the common use case. If multiple finalizers are removed, at least so should Object>>toFinalizeSend:to:with: (and potentially other spots, I haven't checked exactly) leaving Object >> finalize as the only place where finalization actions take place. (Which is where the actions Igor are talking about should be happening in the first place) Cheers, Henry On Sep 23, 2010, at 10:36 27PM, Chris Muller wrote: > I agree that multiple finalizers per object seems unnecessary and, as > you pointed out, potentially confusing, if not also conflicting. > TSTTCPW seems appropriate in this case. > > On Thu, Sep 23, 2010 at 3:23 PM, Igor Stasenko <[hidden email]> wrote: >> Hello, >> >> i'd like to raise this subject once more, because i don't like it (or >> don't understand?). >> >> In all scenarios, where i met the need to use finalization, a single >> finalizer is sufficient. >> Moreover, there is always a single object who controls a weak >> reference, and it never leaks it out, to prevent >> the case, when some other object may obtain a strong reference on it, >> making it permanently held in object memory. >> >> Multiple different finalizers for single object, from design point of >> view, means that you having two different, not related frameworks, >> which using same object, and want to do something when it dies. >> A scenario, where its possible and userful, still don't comes into my mind. >> In contrary, whenever i see a use of finalizers, its in most cases >> about graceful control over external resource, such as: >> - file >> - socket >> - external memory >> >> and i really don't see how multiple finalizers per single resource >> could do any good. >> >> Suppose one finalizer closing a file handle, while another one >> flushing it buffer cache. >> Now, how you going to ensure, that one finalizer will execute first, >> before another one? >> And what if third framework comes into play and wants to add another >> finalizer on top of that, which should do something in the middle >> between flushing a cache and closing file handle? >> >>> From the above, the only conclusion can be made: use a single >> finalizer, and put all logic & operation ordering into it. >> And also, prevent leakage of object pointer (such as file handle) >> outside of your model, otherwise it may cause harm. >> >> That's why i think a current WeakRegistry model provoking bad design practices. >> I think a better behavior would be to raise an error, if something >> wants to register finalizer twice for a single object. >> >> >> -- >> 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 |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |