summaryrefslogtreecommitdiffstats
path: root/Lib
diff options
context:
space:
mode:
authorGuido van Rossum <guido@python.org>2000-04-24 15:40:53 (GMT)
committerGuido van Rossum <guido@python.org>2000-04-24 15:40:53 (GMT)
commite92e610a9e0ec78bf9dd4965b980f1b57eeb040e (patch)
tree460bc78b7e874de9aa11d45f14f3414a90488ab3 /Lib
parentdb575db0d6503a8acdb0f56ce74a339bf63c9a08 (diff)
downloadcpython-e92e610a9e0ec78bf9dd4965b980f1b57eeb040e.zip
cpython-e92e610a9e0ec78bf9dd4965b980f1b57eeb040e.tar.gz
cpython-e92e610a9e0ec78bf9dd4965b980f1b57eeb040e.tar.bz2
Christian Tismer -- total rewrite on trashcan code.
Improvements: - does no longer need any extra memory - has no relationship to tstate - works in debug mode - can easily be modified for free threading (hi Greg:) Side effects: Trashcan does change the order of object destruction. Prevending that would be quite an immense effort, as my attempts have shown. This version works always the same, with debug mode or not. The slightly changed destruction order should therefore be no problem. Algorithm: While the old idea of delaying the destruction of some obejcts at a certain recursion level was kept, we now no longer aloocate an object to hold these objects. The delayed objects are instead chained together via their ob_type field. The type is encoded via ob_refcnt. When it comes to the destruction of the chain of waiting objects, the topmost object is popped off the chain and revived with type and refcount 1, then it gets a normal Py_DECREF. I am confident that this solution is near optimum for minimizing side effects and code bloat.
Diffstat (limited to 'Lib')
0 files changed, 0 insertions, 0 deletions