- 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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
