[Pharo-project] 12186 image quit problem

Schwab,Wilhelm K bschwab at anest.ufl.edu
Sat Oct 9 18:05:49 EDT 2010


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: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Eliot Miranda [eliot.miranda at gmail.com]
Sent: Saturday, October 09, 2010 5:24 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] 12186 image quit problem

On Sat, Oct 9, 2010 at 2:05 PM, Schwab,Wilhelm K <bschwab at anest.ufl.edu<mailto:bschwab at anest.ufl.edu>> 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: pharo-project-bounces at lists.gforge.inria.fr<mailto:pharo-project-bounces at lists.gforge.inria.fr> [pharo-project-bounces at lists.gforge.inria.fr<mailto:pharo-project-bounces at lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua at gmail.com<mailto:siguctua at gmail.com>]
Sent: Saturday, October 09, 2010 11:38 AM
To: Pharo-project at lists.gforge.inria.fr<mailto:Pharo-project at lists.gforge.inria.fr>
Subject: Re: [Pharo-project] 12186 image quit problem

On 9 October 2010 09:02, Stéphane Ducasse <stephane.ducasse at inria.fr<mailto:stephane.ducasse at inria.fr>> 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
> Pharo-project at lists.gforge.inria.fr<mailto:Pharo-project at 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 at lists.gforge.inria.fr<mailto:Pharo-project at lists.gforge.inria.fr>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr<mailto:Pharo-project at lists.gforge.inria.fr>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project





More information about the Pharo-dev mailing list