On Sat, Oct 9, 2010 at 2:05 PM, Schwab,Wilhelm K <[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] [ > [email protected]] On Behalf Of Igor Stasenko [ > [email protected]] > Sent: Saturday, October 09, 2010 11:38 AM > To: [email protected] > Subject: Re: [Pharo-project] 12186 image quit problem > > On 9 October 2010 09:02, Stéphane Ducasse <[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] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [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 >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
