No argument there. You might have had better weak collections to work with, but hopefully things like Cog and Sig's finalization improvements will give us similar advantages. Either way, it is important to have good session start/stop awareness and to sever ties at the right time (and to not do so at the wrong times).
________________________________________ From: [email protected] [[email protected]] On Behalf Of Eliot Miranda [[email protected]] Sent: Saturday, October 09, 2010 5:24 PM To: [email protected] Subject: Re: [Pharo-project] 12186 image quit problem On Sat, Oct 9, 2010 at 2:05 PM, Schwab,Wilhelm K <[email protected]<mailto:[email protected]>> wrote: Sig, Ignore this if you see fit; it might not apply, but don't dismiss it too quickly - it will apply somewhere, somehow. First, are these things happening on shutdown, or on image save? I ask because while they seem to be getting straightened out over time, those concepts have long been intermingled to disadvantage that appears to be greatly underestimated. The correct solution to many startup/shtudown cleanup takes some adjustment. Image save is nothing - ignore it. Shutdown can almost be ignored, though it is wise and polite to try to clean up external resources, and we should have good tools for developers wanting/needing to do so in their own programs. A good OS will clean up resources when something quits, but Andreas and others would point out that there might not be an OS, or it might have been written in the north western US :) The real house cleaning magic happens on startup - all the stuff you bravely ignored on save is now, finally, junk and needs to be discarded. By following this approach, an image save is no big deal, the system does the best it can to clean up after itself on shutdown, and things that were retained post-save (because the image needs to be able to plod along as though nothing happened) get chopped out early in startup and lazily recreated when appropriate. But remember it is far more efficient in start-up time to use a weak collection of objects that need to be junked/voided/finalized than an allInstancesDo: or two. I made VisualWorks start up about 4 times quicker by e.g. keeping font instances in a collection for voiding their handles on start-up. Bill ________________________________________ From: [email protected]<mailto:[email protected]> [[email protected]<mailto:[email protected]>] On Behalf Of Igor Stasenko [[email protected]<mailto:[email protected]>] Sent: Saturday, October 09, 2010 11:38 AM To: [email protected]<mailto:[email protected]> Subject: Re: [Pharo-project] 12186 image quit problem On 9 October 2010 09:02, Stéphane Ducasse <[email protected]<mailto:[email protected]>> wrote: > Igor > > Is it also related to > http://code.google.com/p/pharo/issues/detail?id=3048 > too? > related? not quite. However by fixing it we at least hide the problem. Somehow , removing weakdependent during shutdown leads to semaphore deadlock. But i don't think that it exactly because MCMethodDefinition registers weakdependent. It could be any other thing, which registers weakdependent and then tries to remove it from weakdependents during shutdown. It also quite hard to reproduce. I was able to lock image few times using script , which Pavel provided. But then running same image with same VM again, didn't lead to lock. > Stef > >>>>>> with the MCMethodDefinition>>shutdown hack it work well >> > > > _______________________________________________ > Pharo-project mailing list > [email protected]<mailto:[email protected]> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected]<mailto:[email protected]> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected]<mailto:[email protected]> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
