[Pharo-project] 12186 image quit problem

Pavel Krivanek pavel.krivanek at gmail.com
Mon Oct 11 04:41:19 EDT 2010


Ok, I opened an issue: http://code.google.com/p/pharo/issues/detail?id=3091

<http://code.google.com/p/pharo/issues/detail?id=3091>The patch works for
me, Thank you Igor.

Cheers,
-- Pavel

On Sun, Oct 10, 2010 at 6:46 PM, Igor Stasenko <siguctua at gmail.com> wrote:

> On 10 October 2010 17:40, Schwab,Wilhelm K <bschwab at anest.ufl.edu> wrote:
> > Sig,
> >
> > Have you thought about using a Mutex?  Maybe I'm missing something in
> life, but long ago I decided the #forMutualExclusion is *beyond* private.
>  Semaphores are wonderful for #wait/#signal.  But for #critical:, I use
> Mutex which won't deadlock a thread with itself.
> >
>
> yes,  i thought about it. It wont help in this situation,
> because if you start modifying dictionary inside a loop, which
> scanning its elements (like #do:)
> you'll have very unpleasant results.
>
> All HostSystemMenusProxy doing during #finalize is removing itself
> from weakregistry (which is complete nonsense, since weak registry
> cleaning itself from dead stuff anyways).
> So,
>  self protected: [
>        valueDictionary expiredValuesDo: [:finItem |
>                finItem finalizeValues  ].
>  ].
>
> actually triggers a bug/mistake in HostSystemMenusProxy , which leads
> to deadlock.
> :)
>
> > 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: Sunday, October 10, 2010 7:56 AM
> > To: Pharo-project at lists.gforge.inria.fr
> > Subject: Re: [Pharo-project] 12186 image quit problem
> >
> > OKay, now i see what the problem:
> >
> > <weak registry protected>
> >   <finalize items>
> >       <HostSystemMenusProxy>>finalize>
> >            ....
> >            <HostSystemMenusProxy class>>unregister>
> >              <weak registry protected>
> >
> >
> > In my WeakRegistry, a #finalize message sent while registry semaphore
> locked,
> > so, in case if object in #finalize trying to manipulate with registry
> > then it going to deadlock.
> >
> > Then following piece:
> >
> > WeakRegistry>>finalizeValues
> >
> > self protected: [
> >        valueDictionary expiredValuesDo: [:finItem |
> >                finItem finalizeValues  ].
> >  ].
> >
> > should be rewritten as:
> >
> > | expired |
> > expired := OrderedCollection new.
> > self protected: [
> >        valueDictionary expiredValuesDo: [:finItem | expired add: finItem
> ]
> >  ].
> > expired do: #finalizeValues.
> >
> >
> > But either way, HostSystemMenusProxy should not attempt remove itself
> > from registry during #finalize (and causing a deadlock),
> > since its pointless.
> >
> >
> > --
> > 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
> >
>
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20101011/a4dc1e8f/attachment-0001.html>


More information about the Pharo-dev mailing list