[Pharo-project] 12186 image quit problem

Eliot Miranda eliot.miranda at gmail.com
Sat Oct 9 17:24:11 EDT 2010


On Sat, Oct 9, 2010 at 2:05 PM, Schwab,Wilhelm K <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 [
> 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
> 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
> > 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
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20101009/88d3085a/attachment-0001.html>


More information about the Pharo-dev mailing list