iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Wrap at fewer columns.

This commit is contained in:
Antoine Pitrou 2013-05-18 11:00:19 +02:00
parent e7e1852be5
commit b5146db1e9
1 changed files with 19 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
pep-0442.txt
View File

@ -54,9 +54,9 @@ Cyclic garbage collector (GC)
Cyclic trash (CT)
A reference cycle, or former reference cycle, in which no object
is referenced from outside the cycle *and* whose objects have
started being cleared by the GC. Objects in cyclic trash are potential
zombies; if they are accessed by Python code, the symptoms can vary
from weird AttributeErrors to crashes.
started being cleared by the GC. Objects in cyclic trash are
potential zombies; if they are accessed by Python code, the symptoms
can vary from weird AttributeErrors to crashes.
Zombie / broken object
An object part of cyclic trash. The term stresses that the object
@ -67,13 +67,13 @@ Zombie / broken object
Finalizer
A function or method called when an object is intended to be
disposed of. The finalizer can access the object and release any
resource held by the object (for example mutexes or file descriptors).
An example is a ``__del__`` method.
resource held by the object (for example mutexes or file
descriptors). An example is a ``__del__`` method.
Resurrection
The process by which a finalizer creates a new reference to an
object in a CI. This can happen as a quirky but supported side-effect
of ``__del__`` methods.
object in a CI. This can happen as a quirky but supported
side-effect of ``__del__`` methods.
Impact
@ -123,23 +123,24 @@ Disposal of cyclic isolates
---------------------------
Cyclic isolates are first detected by the garbage collector, and then
disposed of. The detection phase doesn't change and won't be described here.
Disposal of a CI traditionally works in the following order:
disposed of. The detection phase doesn't change and won't be described
here. Disposal of a CI traditionally works in the following order:
1. Weakrefs to CI objects are cleared, and their callbacks called. At this
point, the objects are still safe to use.
1. Weakrefs to CI objects are cleared, and their callbacks called. At
this point, the objects are still safe to use.
2. The CI becomes a CT as the GC systematically breaks all
known references inside it (using the ``tp_clear`` function).
3. Nothing. All CT objects should have been disposed of in step 2
(as a side-effect of clearing references); this collection is finished.
(as a side-effect of clearing references); this collection is
finished.
This PEP proposes to turn CI disposal into the following sequence (new
steps are in bold):
1. Weakrefs to CI objects are cleared, and their callbacks called. At this
point, the objects are still safe to use.
1. Weakrefs to CI objects are cleared, and their callbacks called. At
this point, the objects are still safe to use.
2. **The finalizers of all CI objects are called.**
@ -152,7 +153,8 @@ steps are in bold):
known references inside it (using the ``tp_clear`` function).
5. Nothing. All CT objects should have been disposed of in step 4
(as a side-effect of clearing references); this collection is finished.
(as a side-effect of clearing references); this collection is
finished.
C-level changes
@ -172,8 +174,8 @@ for testing purposes).
On the internal side, a bit is reserved in the GC header for GC-managed
objects to signal that they were finalized. This helps avoid finalizing
an object twice (and, especially, finalizing a CT object after it was broken
by the GC).
an object twice (and, especially, finalizing a CT object after it was
broken by the GC).
Discussion