[Pharo-project] 12186 image quit problem

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


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.


From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua at gmail.com]
Sent: Saturday, October 09, 2010 11:38 AM
To: 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> 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
It could be any other thing, which registers weakdependent and then
tries to remove it from weakdependents during

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
> 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

More information about the Pharo-dev mailing list