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

Igor Stasenko siguctua at gmail.com
Mon Oct 11 07:04:58 EDT 2010


- 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 at 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 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
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.




More information about the Pharo-dev mailing list