[squeak-dev] Re: [Pharo-project] 12186 image quit problem

Stéphane Ducasse stephane.ducasse at inria.fr
Mon Oct 11 11:01:26 UTC 2010


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 at 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 at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project




More information about the Squeak-dev mailing list