[squeak-dev] Re: [Pharo-project] 12186 image quit problem
Igor Stasenko
siguctua at gmail.com
Mon Oct 11 09:46:47 UTC 2010
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 ;)).
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WeakRegistry-finalizeValues.st
Type: application/octet-stream
Size: 1075 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20101011/92d0b3a6/WeakRegistry-finalizeValues.obj
More information about the Squeak-dev
mailing list
|