Sig, As a friend here: when did I say I'd remove all? Remove and process one at a time. I will admit to having a bias toward doing this with a single executor per object, but even if multiples turn out to have value (need to hunt down and read Levente's description of that), the same idea should apply. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Monday, October 11, 2010 1:39 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Another finalization concern: error handling On 11 October 2010 20:04, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Sig,
Understood, but are they all that different? The ones that were served ahead of the error should stay that way (proper recording of same is what needs attention), and those yet to be served, if it's done well, should be ready for the new thread to handle. Just something to consider.
Devil is always in details. The problem can be illustrated by following: | todoList | todoList := collection select: [ some criteria ]. collection removeAllFoundIn: todoList. todoList do: [ :each | each doSomething ]. now, if inside of #doSomething you got an error, a loop is interrupted, and if you restart the process, your todoList temp is gone, since it is local to particular context, which will be discarded. You also can't restore todoList by rescanning a collection, since you removed all elements, which met your criteria.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Monday, October 11, 2010 1:02 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Another finalization concern: error handling
On 11 October 2010 19:28, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Sig,
The Dolphin approach is to restart any of the finalizer, main, timer, idler threads (I *think* there is one more in a baseline image) any time they quit; an #ensure: block forks a new thread of the type that terminated. That way, whether they are taken down by an error doing what they are supposed to do or just by a stray #terminate or mistake with an attached debugger, the system rolls onward intact.
If it would be only about restarting, then its a piece of cake. We should make sure that all finalizations detected prior to error, did not get lost and are able to proceed as if nothing happens, except a single one, which failed with error.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Monday, October 11, 2010 12:14 PM To: Pharo-project@lists.gforge.inria.fr; The general-purpose Squeak developers list Subject: Re: [Pharo-project] Another finalization concern: error handling
Meanwhile, i'll try to implement two test cases for WeakRegistryTest.
One, should cover following:
coll := OrderedCollection new. obj := Object new. wrapper := WeakArray with: obj. coll add: wrapper.
obj toFinalizeSend: #remove: to: coll with: wrapper. obj toFinalizeSend: #remove: to: coll with: wrapper. obj toFinalizeSend: #remove: to: coll with: wrapper. obj toFinalizeSend: #remove: to: coll with: wrapper.
obj := nil. Smalltalk garbageCollect.
i.e somehow, user should be notified that there is an error during finalization.
And second test case is to make sure that if one finalizer unable to complete due to error, the other ones (and finalization process itself) should continue running, skipping over errorneous finalizer.
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project