Multiple finalizers per single object
Locked
12
12
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. |
Re: 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. > > |
Re: Multiple finalizers per single object
|
|
In reply to this post by Igor Stasenko
Isn't that a bit of a made-up problem? I've never seen (nor heard of)
anyone even trying to attach more than one finalizer to an object. Disallowing it could be done, but unless there's a good reason for it I'm not in favor of deciding what is good policy and what isn't without a practical use case at hand. If you have a use-case I'd like to hear more about it, but if not, then *shrug*, who cares :-) Cheers, - Andreas On 9/23/2010 1:23 PM, Igor Stasenko 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. > > |
Re: Multiple finalizers per single object
|
|
In reply to this post by Igor Stasenko
Igor,
On Thu, Sep 23, 2010 at 1:23 PM, Igor Stasenko <[hidden email]> wrote: Hello, This is a straw man since actions compose. i.e. if one wanted multiple finalization actions on a single object one would create a unitary action that invoked multiple sub-actions. i.e. you can lift the problem up. If someone ever needs multiple finalization actions they can query the existing finalization action, compose this with a new finalization action and install the compound as the single action.
2¢ Eliot
|
Re: Multiple finalizers per single object
|
|
In reply to this post by Andreas.Raab
On 23 September 2010 23:58, Andreas Raab <[hidden email]> wrote:
> Isn't that a bit of a made-up problem? I've never seen (nor heard of) anyone > even trying to attach more than one finalizer to an object. Disallowing it > could be done, but unless there's a good reason for it I'm not in favor of > deciding what is good policy and what isn't without a practical use case at > hand. If you have a use-case I'd like to hear more about it, but if not, > then *shrug*, who cares :-) > The practical use, that one may mistakenly add two same finalizers on a same object, like closing a file handle, or free external memory. And it is potentially dangerous, because OS could reuse the same memory location or file handle, once you closed it, so, by closing it twice you can get a serious trouble finding what's going on. My point, that if one ever needs a composite finalization action, a WeakRegistry is wrong place for that. WeakRegistry should prevent registering more than a signle finalizer per unique object to prevent potential problems which could arise from such composition(s). > Cheers, > - Andreas > > On 9/23/2010 1:23 PM, Igor Stasenko 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. |
Re: Multiple finalizers per single object
|
|
In reply to this post by Eliot Miranda-2
On 24 September 2010 00:09, Eliot Miranda <[hidden email]> wrote:
> Igor, > > On Thu, Sep 23, 2010 at 1: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?). > > This is a straw man since actions compose. i.e. if one wanted multiple > finalization actions on a single object one would create a unitary action > that invoked multiple sub-actions. i.e. you can lift the problem up. If > someone ever needs multiple finalization actions they can query the existing > finalization action, compose this with a new finalization action and install > the compound as the single action. > 2¢ Right, i am exactly about that - lift the problem up. The entity, which holding an exclusive control over some external resource, may do a composite actions while finalizing it. And from WeakRegistry side it should be seen as a single finalization action, not multiple ones. Because otherwise, as i said before, allowing installing multiple finalizations using WeakRegistry, feels like two (or more) unrelated entities trying to hold an exclusive control over some resource. Which never should happen in well-designed model. > Eliot >> >> 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. >> > > > > > -- Best regards, Igor Stasenko AKA sig. |
Re: Multiple finalizers per single object
|
|
In reply to this post by Igor Stasenko
On 9/23/2010 3:27 PM, Igor Stasenko wrote:
> On 23 September 2010 23:58, Andreas Raab<[hidden email]> wrote: >> Isn't that a bit of a made-up problem? I've never seen (nor heard of) anyone >> even trying to attach more than one finalizer to an object. Disallowing it >> could be done, but unless there's a good reason for it I'm not in favor of >> deciding what is good policy and what isn't without a practical use case at >> hand. If you have a use-case I'd like to hear more about it, but if not, >> then *shrug*, who cares :-) >> > > The practical use, that one may mistakenly add two same finalizers on > a same object, > like closing a file handle, or free external memory. > And it is potentially dangerous, because OS could reuse the same > memory location or file handle, > once you closed it, so, by closing it twice you can get a serious > trouble finding what's going on. > > My point, that if one ever needs a composite finalization action, a > WeakRegistry is wrong place for that. > WeakRegistry should prevent registering more than a signle finalizer > per unique object to prevent > potential problems which could arise from such composition(s). So you're saying one *could* do that and *if* one did that it *might* lead to a *potential* issue? Sounds like solving a non-problem to me :-) (but go ahead and fix it if you feel that it needs fixing) Cheers, - Andreas > >> Cheers, >> - Andreas >> >> On 9/23/2010 1:23 PM, Igor Stasenko 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. >>> >>> >> >> >> > > > |
Re: Multiple finalizers per single object
|
|
On 24 September 2010 01:40, Andreas Raab <[hidden email]> wrote:
> On 9/23/2010 3:27 PM, Igor Stasenko wrote: >> >> On 23 September 2010 23:58, Andreas Raab<[hidden email]> wrote: >>> >>> Isn't that a bit of a made-up problem? I've never seen (nor heard of) >>> anyone >>> even trying to attach more than one finalizer to an object. Disallowing >>> it >>> could be done, but unless there's a good reason for it I'm not in favor >>> of >>> deciding what is good policy and what isn't without a practical use case >>> at >>> hand. If you have a use-case I'd like to hear more about it, but if not, >>> then *shrug*, who cares :-) >>> >> >> The practical use, that one may mistakenly add two same finalizers on >> a same object, >> like closing a file handle, or free external memory. >> And it is potentially dangerous, because OS could reuse the same >> memory location or file handle, >> once you closed it, so, by closing it twice you can get a serious >> trouble finding what's going on. >> >> My point, that if one ever needs a composite finalization action, a >> WeakRegistry is wrong place for that. >> WeakRegistry should prevent registering more than a signle finalizer >> per unique object to prevent >> potential problems which could arise from such composition(s). > > So you're saying one *could* do that and *if* one did that it *might* lead > to a *potential* issue? Sounds like solving a non-problem to me :-) > Yes i consider it as a potential security hole. It simply feels wrong to me. It is good that nobody using multiple finalizers. Okay, then why they are here? Code should have a practical use, otherwise it is just a garbage, no? Or is it an invitation to start using them? I'm not envy to everyone who will start doing it. :) I'd really like to see a good practical example where such thing could be userful, which outweights a potential problems i described before. > (but go ahead and fix it if you feel that it needs fixing) > > Cheers, > - Andreas > >> >>> Cheers, >>> - Andreas >>> >>> On 9/23/2010 1:23 PM, Igor Stasenko 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. |
Re: Multiple finalizers per single object
|
|
On Fri, 24 Sep 2010, Igor Stasenko wrote:
> On 24 September 2010 01:40, Andreas Raab <[hidden email]> wrote: >> On 9/23/2010 3:27 PM, Igor Stasenko wrote: >>> >>> On 23 September 2010 23:58, Andreas Raab<[hidden email]> wrote: >>>> >>>> Isn't that a bit of a made-up problem? I've never seen (nor heard of) >>>> anyone >>>> even trying to attach more than one finalizer to an object. Disallowing >>>> it >>>> could be done, but unless there's a good reason for it I'm not in favor >>>> of >>>> deciding what is good policy and what isn't without a practical use case >>>> at >>>> hand. If you have a use-case I'd like to hear more about it, but if not, >>>> then *shrug*, who cares :-) >>>> >>> >>> The practical use, that one may mistakenly add two same finalizers on >>> a same object, >>> like closing a file handle, or free external memory. >>> And it is potentially dangerous, because OS could reuse the same >>> memory location or file handle, >>> once you closed it, so, by closing it twice you can get a serious >>> trouble finding what's going on. >>> >>> My point, that if one ever needs a composite finalization action, a >>> WeakRegistry is wrong place for that. >>> WeakRegistry should prevent registering more than a signle finalizer >>> per unique object to prevent >>> potential problems which could arise from such composition(s). >> >> So you're saying one *could* do that and *if* one did that it *might* lead >> to a *potential* issue? Sounds like solving a non-problem to me :-) >> > > Yes i consider it as a potential security hole. It simply feels wrong to me. > It is good that nobody using multiple finalizers. Currently our announcement framework uses this feature to remove all weak subscriptions for an object when it's garbage collected. This avoids iterating through all the subscriptions looking for those which don't have a subscriber anymore. I'm sure it could be implemented another way, but it's really simple this way. Levente > Okay, then why they are here? Code should have a practical use, > otherwise it is just a garbage, no? > Or is it an invitation to start using them? > I'm not envy to everyone who will start doing it. :) > > I'd really like to see a good practical example where such thing could > be userful, > which outweights a potential problems i described before. > >> (but go ahead and fix it if you feel that it needs fixing) >> >> Cheers, >> - Andreas >> >>> >>>> Cheers, >>>> - Andreas >>>> >>>> On 9/23/2010 1:23 PM, Igor Stasenko 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. > > |
Re: Multiple finalizers per single object
|
|
2010/9/24 Levente Uzonyi <[hidden email]>:
> On Fri, 24 Sep 2010, Igor Stasenko wrote: > >> On 24 September 2010 01:40, Andreas Raab <[hidden email]> wrote: >>> >>> On 9/23/2010 3:27 PM, Igor Stasenko wrote: >>>> >>>> On 23 September 2010 23:58, Andreas Raab<[hidden email]> wrote: >>>>> >>>>> Isn't that a bit of a made-up problem? I've never seen (nor heard of) >>>>> anyone >>>>> even trying to attach more than one finalizer to an object. Disallowing >>>>> it >>>>> could be done, but unless there's a good reason for it I'm not in favor >>>>> of >>>>> deciding what is good policy and what isn't without a practical use >>>>> case >>>>> at >>>>> hand. If you have a use-case I'd like to hear more about it, but if >>>>> not, >>>>> then *shrug*, who cares :-) >>>>> >>>> >>>> The practical use, that one may mistakenly add two same finalizers on >>>> a same object, >>>> like closing a file handle, or free external memory. >>>> And it is potentially dangerous, because OS could reuse the same >>>> memory location or file handle, >>>> once you closed it, so, by closing it twice you can get a serious >>>> trouble finding what's going on. >>>> >>>> My point, that if one ever needs a composite finalization action, a >>>> WeakRegistry is wrong place for that. >>>> WeakRegistry should prevent registering more than a signle finalizer >>>> per unique object to prevent >>>> potential problems which could arise from such composition(s). >>> >>> So you're saying one *could* do that and *if* one did that it *might* >>> lead >>> to a *potential* issue? Sounds like solving a non-problem to me :-) >>> >> >> Yes i consider it as a potential security hole. It simply feels wrong to >> me. >> It is good that nobody using multiple finalizers. > > How do you know that for sure? > Currently our announcement framework uses this feature to remove all weak > subscriptions for an object when it's garbage collected. This avoids > iterating through all the subscriptions looking for those which don't have a > subscriber anymore. I'm sure it could be implemented another way, but it's > really simple this way. > Though, iterating through all subscriptions, this is what you can avoid using new finalization scheme. When weak field of subscription becomes nil, a subscription will be automatically added to the list of expired subscriptions. Then, after GC, you simply go through that list and remove them from subscriptions container. Note that such implementation doesn't involving WeakRegistry at all, and therefore you won't be needing multiple finalizers per single object. :) > > Levente > >> Okay, then why they are here? Code should have a practical use, >> otherwise it is just a garbage, no? >> Or is it an invitation to start using them? >> I'm not envy to everyone who will start doing it. :) >> >> I'd really like to see a good practical example where such thing could >> be userful, >> which outweights a potential problems i described before. >> >>> (but go ahead and fix it if you feel that it needs fixing) >>> >>> Cheers, >>> - Andreas >>> >>>> >>>>> Cheers, >>>>> - Andreas >>>>> >>>>> On 9/23/2010 1:23 PM, Igor Stasenko 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. >> > > > > -- Best regards, Igor Stasenko AKA sig. |
Re: Multiple finalizers per single object
|
|
On Fri, 24 Sep 2010, Igor Stasenko wrote:
> 2010/9/24 Levente Uzonyi <[hidden email]>: >> On Fri, 24 Sep 2010, Igor Stasenko wrote: >> >>> On 24 September 2010 01:40, Andreas Raab <[hidden email]> wrote: >>>> >>>> On 9/23/2010 3:27 PM, Igor Stasenko wrote: >>>>> >>>>> On 23 September 2010 23:58, Andreas Raab<[hidden email]> wrote: >>>>>> >>>>>> Isn't that a bit of a made-up problem? I've never seen (nor heard of) >>>>>> anyone >>>>>> even trying to attach more than one finalizer to an object. Disallowing >>>>>> it >>>>>> could be done, but unless there's a good reason for it I'm not in favor >>>>>> of >>>>>> deciding what is good policy and what isn't without a practical use >>>>>> case >>>>>> at >>>>>> hand. If you have a use-case I'd like to hear more about it, but if >>>>>> not, >>>>>> then *shrug*, who cares :-) >>>>>> >>>>> >>>>> The practical use, that one may mistakenly add two same finalizers on >>>>> a same object, >>>>> like closing a file handle, or free external memory. >>>>> And it is potentially dangerous, because OS could reuse the same >>>>> memory location or file handle, >>>>> once you closed it, so, by closing it twice you can get a serious >>>>> trouble finding what's going on. >>>>> >>>>> My point, that if one ever needs a composite finalization action, a >>>>> WeakRegistry is wrong place for that. >>>>> WeakRegistry should prevent registering more than a signle finalizer >>>>> per unique object to prevent >>>>> potential problems which could arise from such composition(s). >>>> >>>> So you're saying one *could* do that and *if* one did that it *might* >>>> lead >>>> to a *potential* issue? Sounds like solving a non-problem to me :-) >>>> >>> >>> Yes i consider it as a potential security hole. It simply feels wrong to >>> me. >>> It is good that nobody using multiple finalizers. >> >> How do you know that for sure? >> Currently our announcement framework uses this feature to remove all weak >> subscriptions for an object when it's garbage collected. This avoids >> iterating through all the subscriptions looking for those which don't have a >> subscriber anymore. I'm sure it could be implemented another way, but it's >> really simple this way. >> > This is userful. > Though, iterating through all subscriptions, this is what you can > avoid using new finalization scheme. > > When weak field of subscription becomes nil, a subscription will be > automatically added to the list of expired subscriptions. > Then, after GC, you simply go through that list and remove them from > subscriptions container. > Note that such implementation doesn't involving WeakRegistry at all, > and therefore you won't be needing > multiple finalizers per single object. :) Maybe the best solution is to make the behavior changeable when an object already has a finalizer in a WeakRegistry. With the current WeakRegistry this could be something like: WeakRegistry >> add: anObject executor: anExecutor "Add anObject to the receiver. Store the object as well as the associated executor." self protected: [ (valueDictionary associationAt: anObject ifAbsent: nil) ifNil: [ valueDictionary at: anObject put: anExecutor ] ifNotNil: [ :association | multipleFinalizerPerObjectAction cull: association cull: anExecutor ] ] WeakRegistry >> initialize: n valueDictionary := WeakIdentityKeyDictionary new: n. accessLock := Semaphore forMutualExclusion. multipleFinalizerPerObjectAction := [ :association | self error: association key printString, ' already has an executor!' ]. self installFinalizer. WeakRegistry >> multipleFinalizerPerObjectAction: aBlock multipleFinalizerPerObjectAction := aBlock This way one could - have multiple finalizers per object as it is in Squeak 4.1 - raise an error as you suggested - replace the current executor with the new one (as it was before Squeak 4.1). I don't know if it fits your new WeakRegistry implementation. I'm also not sure if this isn't a bit over-engineered. Levente > >> >> Levente >> >>> Okay, then why they are here? Code should have a practical use, >>> otherwise it is just a garbage, no? >>> Or is it an invitation to start using them? >>> I'm not envy to everyone who will start doing it. :) >>> >>> I'd really like to see a good practical example where such thing could >>> be userful, >>> which outweights a potential problems i described before. >>> >>>> (but go ahead and fix it if you feel that it needs fixing) >>>> >>>> Cheers, >>>> - Andreas >>>> >>>>> >>>>>> Cheers, >>>>>> - Andreas >>>>>> >>>>>> On 9/23/2010 1:23 PM, Igor Stasenko 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. >>> >> >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > |
Re: Multiple finalizers per single object
|
|
2010/9/24 Levente Uzonyi <[hidden email]>:
> On Fri, 24 Sep 2010, Igor Stasenko wrote: > >> 2010/9/24 Levente Uzonyi <[hidden email]>: >>> >>> On Fri, 24 Sep 2010, Igor Stasenko wrote: >>> >>>> On 24 September 2010 01:40, Andreas Raab <[hidden email]> wrote: >>>>> >>>>> On 9/23/2010 3:27 PM, Igor Stasenko wrote: >>>>>> >>>>>> On 23 September 2010 23:58, Andreas Raab<[hidden email]> wrote: >>>>>>> >>>>>>> Isn't that a bit of a made-up problem? I've never seen (nor heard of) >>>>>>> anyone >>>>>>> even trying to attach more than one finalizer to an object. >>>>>>> Disallowing >>>>>>> it >>>>>>> could be done, but unless there's a good reason for it I'm not in >>>>>>> favor >>>>>>> of >>>>>>> deciding what is good policy and what isn't without a practical use >>>>>>> case >>>>>>> at >>>>>>> hand. If you have a use-case I'd like to hear more about it, but if >>>>>>> not, >>>>>>> then *shrug*, who cares :-) >>>>>>> >>>>>> >>>>>> The practical use, that one may mistakenly add two same finalizers on >>>>>> a same object, >>>>>> like closing a file handle, or free external memory. >>>>>> And it is potentially dangerous, because OS could reuse the same >>>>>> memory location or file handle, >>>>>> once you closed it, so, by closing it twice you can get a serious >>>>>> trouble finding what's going on. >>>>>> >>>>>> My point, that if one ever needs a composite finalization action, a >>>>>> WeakRegistry is wrong place for that. >>>>>> WeakRegistry should prevent registering more than a signle finalizer >>>>>> per unique object to prevent >>>>>> potential problems which could arise from such composition(s). >>>>> >>>>> So you're saying one *could* do that and *if* one did that it *might* >>>>> lead >>>>> to a *potential* issue? Sounds like solving a non-problem to me :-) >>>>> >>>> >>>> Yes i consider it as a potential security hole. It simply feels wrong to >>>> me. >>>> It is good that nobody using multiple finalizers. >>> >>> How do you know that for sure? >>> Currently our announcement framework uses this feature to remove all weak >>> subscriptions for an object when it's garbage collected. This avoids >>> iterating through all the subscriptions looking for those which don't >>> have a >>> subscriber anymore. I'm sure it could be implemented another way, but >>> it's >>> really simple this way. >>> >> This is userful. >> Though, iterating through all subscriptions, this is what you can >> avoid using new finalization scheme. >> >> When weak field of subscription becomes nil, a subscription will be >> automatically added to the list of expired subscriptions. >> Then, after GC, you simply go through that list and remove them from >> subscriptions container. >> Note that such implementation doesn't involving WeakRegistry at all, >> and therefore you won't be needing >> multiple finalizers per single object. :) > > I think we can live without multiple finalizers per object. > Maybe the best solution is to make the behavior changeable when an object > already has a finalizer in a WeakRegistry. With the current WeakRegistry > this could be something like: > > WeakRegistry >> add: anObject executor: anExecutor > "Add anObject to the receiver. Store the object as well as the > associated executor." > > self protected: [ > (valueDictionary associationAt: anObject ifAbsent: nil) > ifNil: [ valueDictionary at: anObject put: anExecutor > ] > ifNotNil: [ :association | > multipleFinalizerPerObjectAction > cull: association > cull: anExecutor ] ] > > WeakRegistry >> initialize: n > > valueDictionary := WeakIdentityKeyDictionary new: n. > accessLock := Semaphore forMutualExclusion. > multipleFinalizerPerObjectAction := [ :association | > self error: association key printString, ' already has an > executor!' ]. > self installFinalizer. > > WeakRegistry >> multipleFinalizerPerObjectAction: aBlock > > multipleFinalizerPerObjectAction := aBlock > > > This way one could > - have multiple finalizers per object as it is in Squeak 4.1 > - raise an error as you suggested > - replace the current executor with the new one (as it was before Squeak > 4.1). > > I don't know if it fits your new WeakRegistry implementation. I'm also not > sure if this isn't a bit over-engineered. > I had to resemble same functionality, as in squeak 4.1 , so new registry still supports multiple finalizations per object. Please, try to file-in the code in http://bugs.squeak.org/view.php?id=7473 and see if you have any problems with it. > > Levente > >> >>> >>> Levente >>> >>>> Okay, then why they are here? Code should have a practical use, >>>> otherwise it is just a garbage, no? >>>> Or is it an invitation to start using them? >>>> I'm not envy to everyone who will start doing it. :) >>>> >>>> I'd really like to see a good practical example where such thing could >>>> be userful, >>>> which outweights a potential problems i described before. >>>> >>>>> (but go ahead and fix it if you feel that it needs fixing) >>>>> >>>>> Cheers, >>>>> - Andreas >>>>> >>>>>> >>>>>>> Cheers, >>>>>>> - Andreas >>>>>>> >>>>>>> On 9/23/2010 1:23 PM, Igor Stasenko 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. >>>> >>> >>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- Best regards, Igor Stasenko AKA sig. |
Re: Multiple finalizers per single object
|
|
On Fri, 24 Sep 2010, Igor Stasenko wrote:
> 2010/9/24 Levente Uzonyi <[hidden email]>: >> On Fri, 24 Sep 2010, Igor Stasenko wrote: >> >>> 2010/9/24 Levente Uzonyi <[hidden email]>: >>>> >>>> On Fri, 24 Sep 2010, Igor Stasenko wrote: >>>> >>>>> On 24 September 2010 01:40, Andreas Raab <[hidden email]> wrote: >>>>>> >>>>>> On 9/23/2010 3:27 PM, Igor Stasenko wrote: >>>>>>> >>>>>>> On 23 September 2010 23:58, Andreas Raab<[hidden email]> wrote: >>>>>>>> >>>>>>>> Isn't that a bit of a made-up problem? I've never seen (nor heard of) >>>>>>>> anyone >>>>>>>> even trying to attach more than one finalizer to an object. >>>>>>>> Disallowing >>>>>>>> it >>>>>>>> could be done, but unless there's a good reason for it I'm not in >>>>>>>> favor >>>>>>>> of >>>>>>>> deciding what is good policy and what isn't without a practical use >>>>>>>> case >>>>>>>> at >>>>>>>> hand. If you have a use-case I'd like to hear more about it, but if >>>>>>>> not, >>>>>>>> then *shrug*, who cares :-) >>>>>>>> >>>>>>> >>>>>>> The practical use, that one may mistakenly add two same finalizers on >>>>>>> a same object, >>>>>>> like closing a file handle, or free external memory. >>>>>>> And it is potentially dangerous, because OS could reuse the same >>>>>>> memory location or file handle, >>>>>>> once you closed it, so, by closing it twice you can get a serious >>>>>>> trouble finding what's going on. >>>>>>> >>>>>>> My point, that if one ever needs a composite finalization action, a >>>>>>> WeakRegistry is wrong place for that. >>>>>>> WeakRegistry should prevent registering more than a signle finalizer >>>>>>> per unique object to prevent >>>>>>> potential problems which could arise from such composition(s). >>>>>> >>>>>> So you're saying one *could* do that and *if* one did that it *might* >>>>>> lead >>>>>> to a *potential* issue? Sounds like solving a non-problem to me :-) >>>>>> >>>>> >>>>> Yes i consider it as a potential security hole. It simply feels wrong to >>>>> me. >>>>> It is good that nobody using multiple finalizers. >>>> >>>> How do you know that for sure? >>>> Currently our announcement framework uses this feature to remove all weak >>>> subscriptions for an object when it's garbage collected. This avoids >>>> iterating through all the subscriptions looking for those which don't >>>> have a >>>> subscriber anymore. I'm sure it could be implemented another way, but >>>> it's >>>> really simple this way. >>>> >>> This is userful. >>> Though, iterating through all subscriptions, this is what you can >>> avoid using new finalization scheme. >>> >>> When weak field of subscription becomes nil, a subscription will be >>> automatically added to the list of expired subscriptions. >>> Then, after GC, you simply go through that list and remove them from >>> subscriptions container. >>> Note that such implementation doesn't involving WeakRegistry at all, >>> and therefore you won't be needing >>> multiple finalizers per single object. :) >> >> I think we can live without multiple finalizers per object. >> Maybe the best solution is to make the behavior changeable when an object >> already has a finalizer in a WeakRegistry. With the current WeakRegistry >> this could be something like: >> >> WeakRegistry >> add: anObject executor: anExecutor >> "Add anObject to the receiver. Store the object as well as the >> associated executor." >> >> self protected: [ >> (valueDictionary associationAt: anObject ifAbsent: nil) >> ifNil: [ valueDictionary at: anObject put: anExecutor >> ] >> ifNotNil: [ :association | >> multipleFinalizerPerObjectAction >> cull: association >> cull: anExecutor ] ] >> >> WeakRegistry >> initialize: n >> >> valueDictionary := WeakIdentityKeyDictionary new: n. >> accessLock := Semaphore forMutualExclusion. >> multipleFinalizerPerObjectAction := [ :association | >> self error: association key printString, ' already has an >> executor!' ]. >> self installFinalizer. >> >> WeakRegistry >> multipleFinalizerPerObjectAction: aBlock >> >> multipleFinalizerPerObjectAction := aBlock >> >> >> This way one could >> - have multiple finalizers per object as it is in Squeak 4.1 >> - raise an error as you suggested >> - replace the current executor with the new one (as it was before Squeak >> 4.1). >> >> I don't know if it fits your new WeakRegistry implementation. I'm also not >> sure if this isn't a bit over-engineered. >> > > I had to resemble same functionality, as in squeak 4.1 , so new > registry still supports > multiple finalizations per object. > Please, try to file-in the code in http://bugs.squeak.org/view.php?id=7473 > and see if you have any problems with it. These can be loaded in one shot (the order doesn't matter): phase-0.cs phase-1-weakfinalizationlist.st phase-1-weakfinalizationregistry.st phase-1-weakfinalizeritem.st phase-4-weakfinalizerstest.st This can be the second step, it can be merged with the next one: phase-2-finalizationprocess.1.cs This can be the thrid step, it could be a MC postscript: phase-3-migrating.1.cs I think the migration code should be removed when the integration is done. After installing the code I tried to explore [WeakRegistry allInstances], but got a debugger, because some WeakRegistry instances didn't have their sema variable initialized. After a GC this issue was solved. When I was looking at the changes compared to the current code I found that WeakRegistry >> #keys is not protected in the new version, which may not return all the keys in a rare case. With the current migration technique we lose the history of WeakRegistry. I think it's possible to do the migration without losing the history by simply extending the current class with the new methods (using different names if they already exist), adding the list variable to the current class, then migrating the instances, renaming the clashing methods, finally removing the obsolete stuff. Also a few comments are lost during the migration, those should also restored IMHO. Today or tomorrow I'll check the code more in-depth and prepare mczs from your changesets (if noone else does it before me). Levente > >> >> Levente >> >>> >>>> >>>> Levente >>>> >>>>> Okay, then why they are here? Code should have a practical use, >>>>> otherwise it is just a garbage, no? >>>>> Or is it an invitation to start using them? >>>>> I'm not envy to everyone who will start doing it. :) >>>>> >>>>> I'd really like to see a good practical example where such thing could >>>>> be userful, >>>>> which outweights a potential problems i described before. >>>>> >>>>>> (but go ahead and fix it if you feel that it needs fixing) >>>>>> >>>>>> Cheers, >>>>>> - Andreas >>>>>> >>>>>>> >>>>>>>> Cheers, >>>>>>>> - Andreas >>>>>>>> >>>>>>>> On 9/23/2010 1:23 PM, Igor Stasenko 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. >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > |
Re: Multiple finalizers per single object
|
|
2010/9/24 Levente Uzonyi <[hidden email]>:
> On Fri, 24 Sep 2010, Igor Stasenko wrote: > >> 2010/9/24 Levente Uzonyi <[hidden email]>: >>> >>> On Fri, 24 Sep 2010, Igor Stasenko wrote: >>> >>>> 2010/9/24 Levente Uzonyi <[hidden email]>: >>>>> >>>>> On Fri, 24 Sep 2010, Igor Stasenko wrote: >>>>> >>>>>> On 24 September 2010 01:40, Andreas Raab <[hidden email]> wrote: >>>>>>> >>>>>>> On 9/23/2010 3:27 PM, Igor Stasenko wrote: >>>>>>>> >>>>>>>> On 23 September 2010 23:58, Andreas Raab<[hidden email]> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Isn't that a bit of a made-up problem? I've never seen (nor heard >>>>>>>>> of) >>>>>>>>> anyone >>>>>>>>> even trying to attach more than one finalizer to an object. >>>>>>>>> Disallowing >>>>>>>>> it >>>>>>>>> could be done, but unless there's a good reason for it I'm not in >>>>>>>>> favor >>>>>>>>> of >>>>>>>>> deciding what is good policy and what isn't without a practical use >>>>>>>>> case >>>>>>>>> at >>>>>>>>> hand. If you have a use-case I'd like to hear more about it, but if >>>>>>>>> not, >>>>>>>>> then *shrug*, who cares :-) >>>>>>>>> >>>>>>>> >>>>>>>> The practical use, that one may mistakenly add two same finalizers >>>>>>>> on >>>>>>>> a same object, >>>>>>>> like closing a file handle, or free external memory. >>>>>>>> And it is potentially dangerous, because OS could reuse the same >>>>>>>> memory location or file handle, >>>>>>>> once you closed it, so, by closing it twice you can get a serious >>>>>>>> trouble finding what's going on. >>>>>>>> >>>>>>>> My point, that if one ever needs a composite finalization action, a >>>>>>>> WeakRegistry is wrong place for that. >>>>>>>> WeakRegistry should prevent registering more than a signle finalizer >>>>>>>> per unique object to prevent >>>>>>>> potential problems which could arise from such composition(s). >>>>>>> >>>>>>> So you're saying one *could* do that and *if* one did that it *might* >>>>>>> lead >>>>>>> to a *potential* issue? Sounds like solving a non-problem to me :-) >>>>>>> >>>>>> >>>>>> Yes i consider it as a potential security hole. It simply feels wrong >>>>>> to >>>>>> me. >>>>>> It is good that nobody using multiple finalizers. >>>>> >>>>> How do you know that for sure? >>>>> Currently our announcement framework uses this feature to remove all >>>>> weak >>>>> subscriptions for an object when it's garbage collected. This avoids >>>>> iterating through all the subscriptions looking for those which don't >>>>> have a >>>>> subscriber anymore. I'm sure it could be implemented another way, but >>>>> it's >>>>> really simple this way. >>>>> >>>> This is userful. >>>> Though, iterating through all subscriptions, this is what you can >>>> avoid using new finalization scheme. >>>> >>>> When weak field of subscription becomes nil, a subscription will be >>>> automatically added to the list of expired subscriptions. >>>> Then, after GC, you simply go through that list and remove them from >>>> subscriptions container. >>>> Note that such implementation doesn't involving WeakRegistry at all, >>>> and therefore you won't be needing >>>> multiple finalizers per single object. :) >>> >>> I think we can live without multiple finalizers per object. >>> Maybe the best solution is to make the behavior changeable when an object >>> already has a finalizer in a WeakRegistry. With the current WeakRegistry >>> this could be something like: >>> >>> WeakRegistry >> add: anObject executor: anExecutor >>> "Add anObject to the receiver. Store the object as well as the >>> associated executor." >>> >>> self protected: [ >>> (valueDictionary associationAt: anObject ifAbsent: nil) >>> ifNil: [ valueDictionary at: anObject put: >>> anExecutor >>> ] >>> ifNotNil: [ :association | >>> multipleFinalizerPerObjectAction >>> cull: association >>> cull: anExecutor ] ] >>> >>> WeakRegistry >> initialize: n >>> >>> valueDictionary := WeakIdentityKeyDictionary new: n. >>> accessLock := Semaphore forMutualExclusion. >>> multipleFinalizerPerObjectAction := [ :association | >>> self error: association key printString, ' already has an >>> executor!' ]. >>> self installFinalizer. >>> >>> WeakRegistry >> multipleFinalizerPerObjectAction: aBlock >>> >>> multipleFinalizerPerObjectAction := aBlock >>> >>> >>> This way one could >>> - have multiple finalizers per object as it is in Squeak 4.1 >>> - raise an error as you suggested >>> - replace the current executor with the new one (as it was before Squeak >>> 4.1). >>> >>> I don't know if it fits your new WeakRegistry implementation. I'm also >>> not >>> sure if this isn't a bit over-engineered. >>> >> >> I had to resemble same functionality, as in squeak 4.1 , so new >> registry still supports >> multiple finalizations per object. >> Please, try to file-in the code in http://bugs.squeak.org/view.php?id=7473 >> and see if you have any problems with it. > > I did that this morning. Here's what I found: > > These can be loaded in one shot (the order doesn't matter): > phase-0.cs > phase-1-weakfinalizationlist.st > phase-1-weakfinalizationregistry.st > phase-1-weakfinalizeritem.st > phase-4-weakfinalizerstest.st > > This can be the second step, it can be merged with the next one: > phase-2-finalizationprocess.1.cs > > This can be the thrid step, it could be a MC postscript: > phase-3-migrating.1.cs > > I think the migration code should be removed when the integration is done. > > After installing the code I tried to explore [WeakRegistry allInstances], > but got a debugger, because some WeakRegistry instances didn't have their > sema variable initialized. After a GC this issue was solved. > > When I was looking at the changes compared to the current code I found that > WeakRegistry >> #keys is not protected in the new version, which may not > return all the keys in a rare case. > > With the current migration technique we lose the history of WeakRegistry. I > think it's possible to do the migration without losing the history by simply > extending the current class with the new methods (using different names if > they already exist), adding the list variable to the current class, then > migrating the instances, renaming the clashing methods, finally removing the > obsolete stuff. > Well, it is hard to do with existing registry class, since system should keep running when you doing these changes. So, you simply can't afford to have a half-working WeakRegistry, since it can be put in use at any moment (once GC is triggered it), and you'll get a problem. But if you think that its possible, you can try do that. About losing history: i implemented new class from scratch. Only then, when i added behavior, which automatically detects if VM supports new finalization or not, it became possible to fully replace old WeakRegistry with a new one. > Also a few comments are lost during the migration, those should also > restored IMHO. See above. I did WeakFinalizationRegistry from scratch. Of course i referred to WeakRegistry, when doing that, but its a completely fresh implementation. And yes, I'm not opposed to have more comments in code. So, if you think that some comments from old registry fit well with new implementation, we can add them back. > > Today or tomorrow I'll check the code more in-depth and prepare mczs from > your changesets (if noone else does it before me). > Please, do :) > > Levente > >> >>> >>> Levente >>> >>>> >>>>> >>>>> Levente >>>>> >>>>>> Okay, then why they are here? Code should have a practical use, >>>>>> otherwise it is just a garbage, no? >>>>>> Or is it an invitation to start using them? >>>>>> I'm not envy to everyone who will start doing it. :) >>>>>> >>>>>> I'd really like to see a good practical example where such thing could >>>>>> be userful, >>>>>> which outweights a potential problems i described before. >>>>>> >>>>>>> (but go ahead and fix it if you feel that it needs fixing) >>>>>>> >>>>>>> Cheers, >>>>>>> - Andreas >>>>>>> >>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> - Andreas >>>>>>>>> >>>>>>>>> On 9/23/2010 1:23 PM, Igor Stasenko 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. >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>> >>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- Best regards, Igor Stasenko AKA sig. |
Re: Multiple finalizers per single object
|
Just a thought on finalization in general:
If we only need one finalizer per object, why not just allow a class to implement #finalize that will be called right before the object will be garbage collected? That would be more convenient. Ciao |
Re: Multiple finalizers per single object
|
|
In reply to this post by Igor Stasenko
On 24 September 2010 17:12, Marcel Taeumel
<[hidden email]> wrote: > Just a thought on finalization in general: > > If we only need one finalizer per object, why not just allow a class to implement #finalize that will be called right before the object will be garbage collected? That would be more convenient. > Because a finalization in Squeak is post-mortem action. What you proposing is pre-mortem action, which will require a lot more work and changes in VM. > Ciao > > > -- Best regards, Igor Stasenko AKA sig. |
New finalization support code is in the Trunk now (was: Re: [squeak-dev] Re: Multiple finalizers per single object)
|
|
In reply to this post by Igor Stasenko
On Fri, 24 Sep 2010, Igor Stasenko wrote:
> 2010/9/24 Levente Uzonyi <[hidden email]>: snip >> >> Today or tomorrow I'll check the code more in-depth and prepare mczs from >> your changesets (if noone else does it before me). >> > Please, do :) It's in the Trunk now. I did the following changes: - there was a bug in the evaluated code in WeakFinalizationRegistry class >> #migrateOldRegistries, the first argument of forgetClass:logged: was a Symbol instead of a Class, so WeakFinalizationRegistry was still around. - WeakRegistry >> #keys is now protected - I merged the old comment of WeakRegistry with the new one = I merged phase-0 with phase-1 - I omitted phase-3, because I added the migration code to phase-2 - I omitted phase-4 because those tests are already in the Trunk What I didn't do so far, is that I didn't build a VM with the new finalization support, so someone should check if it works as expected. Levente P.S.: Seems like the MC postscript is evaluated before the class initializers which is a bit surprising. This is why I couldn't merge phase-2 into phase-1. |
Re: New finalization support code is in the Trunk now (was: Re: [squeak-dev] Re: Multiple finalizers per single object)
|
|
Great news! Thanks Levente.
I will test if everything ok on my VM(s), since i have Squeak&Cog with new finalization both :) On 26 September 2010 04:29, Levente Uzonyi <[hidden email]> wrote: > On Fri, 24 Sep 2010, Igor Stasenko wrote: > >> 2010/9/24 Levente Uzonyi <[hidden email]>: > > snip > >>> >>> Today or tomorrow I'll check the code more in-depth and prepare mczs from >>> your changesets (if noone else does it before me). >>> >> Please, do :) > > It's in the Trunk now. I did the following changes: > - there was a bug in the evaluated code in WeakFinalizationRegistry class >> > #migrateOldRegistries, the first argument of forgetClass:logged: was a > Symbol instead of a Class, so WeakFinalizationRegistry was still around. > - WeakRegistry >> #keys is now protected > - I merged the old comment of WeakRegistry with the new one > = I merged phase-0 with phase-1 > - I omitted phase-3, because I added the migration code to phase-2 > - I omitted phase-4 because those tests are already in the Trunk > > What I didn't do so far, is that I didn't build a VM with the new > finalization support, so someone should check if it works as expected. > > > Levente > > P.S.: Seems like the MC postscript is evaluated before the class > initializers which is a bit surprising. This is why I couldn't merge phase-2 > into phase-1. > > -- Best regards, Igor Stasenko AKA sig. |
Re: New finalization support code is in the Trunk now (was: Re: [squeak-dev] Re: Multiple finalizers per single object)
|
|
On Sun, 26 Sep 2010, Igor Stasenko wrote:
> Great news! Thanks Levente. > I will test if everything ok on my VM(s), since i have Squeak&Cog with > new finalization both :) Thanks. Levente > > On 26 September 2010 04:29, Levente Uzonyi <[hidden email]> wrote: >> On Fri, 24 Sep 2010, Igor Stasenko wrote: >> >>> 2010/9/24 Levente Uzonyi <[hidden email]>: >> >> snip >> >>>> >>>> Today or tomorrow I'll check the code more in-depth and prepare mczs from >>>> your changesets (if noone else does it before me). >>>> >>> Please, do :) >> >> It's in the Trunk now. I did the following changes: >> - there was a bug in the evaluated code in WeakFinalizationRegistry class >> >> #migrateOldRegistries, the first argument of forgetClass:logged: was a >> Symbol instead of a Class, so WeakFinalizationRegistry was still around. >> - WeakRegistry >> #keys is now protected >> - I merged the old comment of WeakRegistry with the new one >> = I merged phase-0 with phase-1 >> - I omitted phase-3, because I added the migration code to phase-2 >> - I omitted phase-4 because those tests are already in the Trunk >> >> What I didn't do so far, is that I didn't build a VM with the new >> finalization support, so someone should check if it works as expected. >> >> >> Levente >> >> P.S.: Seems like the MC postscript is evaluated before the class >> initializers which is a bit surprising. This is why I couldn't merge phase-2 >> into phase-1. >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > |
Re: New finalization support code is in the Trunk now (was: Re: [squeak-dev] Re: Multiple finalizers per single object)
|
|
Tested on both Squeak & Cog VMs.
WeakRegistryTest and WeakFinalizersTests are all green. Now all is left is release new VMs with finalization. On 26 September 2010 06:26, Levente Uzonyi <[hidden email]> wrote: > On Sun, 26 Sep 2010, Igor Stasenko wrote: > >> Great news! Thanks Levente. >> I will test if everything ok on my VM(s), since i have Squeak&Cog with >> new finalization both :) > > Thanks. > > > Levente > >> >> On 26 September 2010 04:29, Levente Uzonyi <[hidden email]> wrote: >>> >>> On Fri, 24 Sep 2010, Igor Stasenko wrote: >>> >>>> 2010/9/24 Levente Uzonyi <[hidden email]>: >>> >>> snip >>> >>>>> >>>>> Today or tomorrow I'll check the code more in-depth and prepare mczs >>>>> from >>>>> your changesets (if noone else does it before me). >>>>> >>>> Please, do :) >>> >>> It's in the Trunk now. I did the following changes: >>> - there was a bug in the evaluated code in WeakFinalizationRegistry class >>> >> >>> #migrateOldRegistries, the first argument of forgetClass:logged: was a >>> Symbol instead of a Class, so WeakFinalizationRegistry was still around. >>> - WeakRegistry >> #keys is now protected >>> - I merged the old comment of WeakRegistry with the new one >>> = I merged phase-0 with phase-1 >>> - I omitted phase-3, because I added the migration code to phase-2 >>> - I omitted phase-4 because those tests are already in the Trunk >>> >>> What I didn't do so far, is that I didn't build a VM with the new >>> finalization support, so someone should check if it works as expected. >>> >>> >>> Levente >>> >>> P.S.: Seems like the MC postscript is evaluated before the class >>> initializers which is a bit surprising. This is why I couldn't merge >>> phase-2 >>> into phase-1. >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > -- Best regards, Igor Stasenko AKA sig. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |