Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
C
cpython
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
Kirill Smelkov
cpython
Commits
af0a8830
Commit
af0a8830
authored
Nov 18, 2001
by
Tim Peters
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Relatively large expansion of the docs for gc.garbage.
parent
36515e28
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
19 additions
and
5 deletions
+19
-5
Doc/lib/libgc.tex
Doc/lib/libgc.tex
+19
-5
No files found.
Doc/lib/libgc.tex
View file @
af0a8830
...
...
@@ -79,7 +79,8 @@ Return the current collection thresholds as a tuple of
\end{funcdesc}
The following variable is provided for read-only access:
The following variable is provided for read-only access (you can
mutate its value but should not rebind it):
\begin{datadesc}
{
garbage
}
A list of objects which the collector found to be unreachable
...
...
@@ -88,9 +89,22 @@ contains only objects with \method{__del__()} methods.\footnote{Prior to
Python 2.2, the list contained all instance objects in unreachable
cycles, not only those with
\method
{__
del
__
()
}
methods.
}
Objects that have
\method
{__
del
__
()
}
methods and create part of a reference cycle cause
the entire reference cycle to be uncollectable. If
\constant
{
DEBUG
_
SAVEALL
}
is set, then all unreachable objects will
\method
{__
del
__
()
}
methods and are part of a reference cycle cause
the entire reference cycle to be uncollectable, including objects
not necessarily in the cycle but reachable only from it. Python doesn't
collect such cycles automatically because, in general, it isn't possible
for Python to guess a safe order in which to run the
\method
{__
del
__
()
}
methods. If you know a safe order, you can force the issue by examining
the
\var
{
garbage
}
list, and explicitly breaking cycles due to your
objects within the list. Note that these objects are kept alive even
so by virtue of being in the
\var
{
garbage
}
list, so they should be
removed from
\var
{
garbage
}
too. For example, after breaking cycles, do
\code
{
del gc.garbage[:]
}
to empty the list. It's generally better
to avoid the issue by not creating cycles containing objects with
\method
{__
del
__
()
}
methods, and
\var
{
garbage
}
can be examined in that
case to verify that no such are being created.
If
\constant
{
DEBUG
_
SAVEALL
}
is set, then all unreachable objects will
be added to this list rather than freed.
\end{datadesc}
...
...
@@ -132,5 +146,5 @@ a leaking program.
\begin{datadesc}
{
DEBUG
_
LEAK
}
The debugging flags necessary for the collector to print
information about a leaking program (equal to
\code
{
DEBUG
_
COLLECTABLE |
DEBUG
_
UNCOLLECTABLE | DEBUG
_
INSTANCES | DEBUG
_
OBJECTS | DEBUG
_
SAVEALL
}
).
DEBUG
_
UNCOLLECTABLE | DEBUG
_
INSTANCES | DEBUG
_
OBJECTS | DEBUG
_
SAVEALL
}
).
\end{datadesc}
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment