Changes between Version 1 and Version 2 of Ticket #715, comment 204


Ignore:
Timestamp:
08/16/12 14:16:10 (10 years ago)
Author:
SimonKing
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #715, comment 204

    v1 v2  
    99Instead, each triple of memory locations points to exactly one triple of references. The triple of references is popped off the dictionary as soon as any weak-refed member of the key triple was garbage collected. Note that the `if len(L)==0:` bit is not needed.
    1010
    11 Another advantage: If the `TripleDicct` is deallocated, then the strong references associated with the `TripleDict` will vanish as well, which wouldn't have been the case with the old code.
     11Another advantage: If the `TripleDict` is deallocated, then the strong references associated with the `TripleDict` will vanish as well, which wouldn't have been the case with the old code.
    1212
    13 Currently, there is only one bad situation I can think of: Let P be an object that can not be weak-refed, has a `TripleDict` T as an attribute, is used as a key in T, and has a `__del__` method. Then the reference cycle P->T->T._refcache->P will keep P alive. However, if any of the four assumptions does not hold, then P can be garbage collected. I think we can take that chance.
    14 
     13Currently, there is only one bad situation I can think of: Let P be an object that can not be weak-refed, has a `TripleDict` T as an attribute, is used as a key in T, and has a `__del__` method. Then the reference cycle P->T->T._refcache->P will keep P alive. However, if any of the four assumptions does not hold, then P can be garbage collected. I think we can take that risk.
    1514Is there any question of yours that I forgot to address?
    1615