- i added a test to cover this issue http://code.google.com/p/pharo/issues/detail?id=3092 On 11 October 2010 14:01, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Thanks. So let's see what is the best choice and tell us.
On Oct 11, 2010, at 11:47 AM, Igor Stasenko wrote:
On 11 October 2010 12:10, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I integrate     Issue 3086:   MCMethodDefinition>>shutdown hack to avoid lock down.     http://code.google.com/p/pharo/issues/detail?id=3086
Igor can you have a look and let me know:     1- if we should rollback Issue 3086:   MCMethodDefinition>>shutdown hack to avoid lock down.     2- if we should integrate         Issue 3048:   MC method cache fix         http://code.google.com/p/pharo/issues/detail?id=3048
I will integrate     http://code.google.com/p/pharo/issues/detail?id=3091
Wait , MCMethodDefinition is only a consequence (however, removing it from weakdependents would be good idea as well ;)).
Yes I integrate it to avoid system hanging.
The real cultprit is HostSystemMenusProxy , which locks the weak registry during finalization. Then MCMethodDefinition>>shutdown simply locks at same point (trying to obtain semaphore lock). Note, that HostSystemMenusProxy locks finalization process, but not the process which doing shutdown, and then during image startup, a new finalization process get created. That's why removing access to weakdependents in MCMethodDefinition>>shutdown , kinda solved the issue. In reality its not. An old weak registry were sending #finalize outside a critical section:
finalizeValues    "Some of our elements may have gone away. Look for those and activate the associated executors."    | finiObjects |    finiObjects := nil.    "First collect the objects."    self protected:[        valueDictionary allAssociationsDo:[:assoc|            assoc key isNil ifTrue:[                finiObjects isNil                    ifTrue:[finiObjects := OrderedCollection with: assoc value]                    ifFalse:[finiObjects add: assoc value]]        ].        finiObjects isNil ifFalse:[valueDictionary finalizeValues: finiObjects asArray].    ].    "Then do the finalization"    finiObjects isNil ifTrue:[^self].    finiObjects do:[:each| each finalize].
So, there two ways to solve it: a) perform finalization outside a critical section (see attached) b) fix the HostSystemMenusProxy to prevent any manupulation with weak registry during finalization.
I checked Squeak 4.2 image, and i can also say, that any attempt to manipulate weak registry during finalization will also lock down a finalization process (see Squeak's WeakRegistry>>finalizeValues & WeakKeyDictionary>>finalizeValues)
So, if we going to assume, in future that it is error to modify weak registry during finalization, then we should leave the code in WeakRegistry as-is, and fix HostSystemMenusProxy instead. If not, the we should make sure that #finalize should be sent outside weak registry's critical section.
And the last note: if VM supports new finalization, it will happen outside a critical section (See the bottom of WeakRegistry>>finalizeValues). So any manipulations with registry during finalization can't cause lockdown.
P.S. forwarded to Squeak-dev, to make Squeakers aware of potential danger , when manipulating weak registry during finalization.
-- Best regards, Igor Stasenko AKA sig. <WeakRegistry-finalizeValues.st>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.