Some nits
This commit is contained in:
parent
6337ff8cdc
commit
a8c93a3627
14
pep-0556.rst
14
pep-0556.rst
|
@ -143,7 +143,7 @@ An internal structure ``gc_mutex`` is added to avoid two GC runs at once:
|
||||||
.. code-block::
|
.. code-block::
|
||||||
|
|
||||||
static struct {
|
static struct {
|
||||||
PyThread_type_lock collecting; /* taken when collecting */
|
PyThread_type_lock lock; /* taken when collecting */
|
||||||
PyThreadState *owner; /* whichever thread is currently collecting
|
PyThreadState *owner; /* whichever thread is currently collecting
|
||||||
(NULL if no collection is taking place) */
|
(NULL if no collection is taking place) */
|
||||||
} gc_mutex;
|
} gc_mutex;
|
||||||
|
@ -203,6 +203,9 @@ and live inside the ``gc`` module, unless otherwise noted:
|
||||||
|
|
||||||
|
|
||||||
def lock_and_collect(generation=-1):
|
def lock_and_collect(generation=-1):
|
||||||
|
"""
|
||||||
|
Perform a collection with thread safety.
|
||||||
|
"""
|
||||||
me = PyThreadState_GET()
|
me = PyThreadState_GET()
|
||||||
if gc_mutex.owner == me:
|
if gc_mutex.owner == me:
|
||||||
# reentrant GC collection request, bail out
|
# reentrant GC collection request, bail out
|
||||||
|
@ -213,7 +216,7 @@ and live inside the ``gc`` module, unless otherwise noted:
|
||||||
gc_mutex.owner = me
|
gc_mutex.owner = me
|
||||||
try:
|
try:
|
||||||
if generation >= 0:
|
if generation >= 0:
|
||||||
return collect_generation(generation)
|
return collect_with_callback(generation)
|
||||||
else:
|
else:
|
||||||
return collect_generations()
|
return collect_generations()
|
||||||
finally:
|
finally:
|
||||||
|
@ -241,6 +244,9 @@ and live inside the ``gc`` module, unless otherwise noted:
|
||||||
|
|
||||||
|
|
||||||
def PyGC_Malloc():
|
def PyGC_Malloc():
|
||||||
|
"""
|
||||||
|
Allocate a GC-enabled object.
|
||||||
|
"""
|
||||||
# Update allocation statistics (same code as currently, omitted for brievity)
|
# Update allocation statistics (same code as currently, omitted for brievity)
|
||||||
if is_implicit_gc_desired():
|
if is_implicit_gc_desired():
|
||||||
if gc_is_threaded:
|
if gc_is_threaded:
|
||||||
|
@ -308,7 +314,7 @@ and live inside the ``gc`` module, unless otherwise noted:
|
||||||
Schedule collection of the given generation and wait for it to
|
Schedule collection of the given generation and wait for it to
|
||||||
finish.
|
finish.
|
||||||
"""
|
"""
|
||||||
return lock_and_collect(collection)
|
return lock_and_collect(generation)
|
||||||
|
|
||||||
|
|
||||||
Discussion
|
Discussion
|
||||||
|
@ -328,7 +334,7 @@ for example if finalizers rely on some thread-local values.
|
||||||
Explicit collections
|
Explicit collections
|
||||||
--------------------
|
--------------------
|
||||||
|
|
||||||
One may ask why explicit collections should not also be delegated to the
|
One may ask whether explicit collections should also be delegated to the
|
||||||
background thread. The answer is it doesn't really matter: since
|
background thread. The answer is it doesn't really matter: since
|
||||||
``gc.collect`` and ``PyGC_Collect`` actually *wait* for the collection to
|
``gc.collect`` and ``PyGC_Collect`` actually *wait* for the collection to
|
||||||
end (breaking this property would break compatibility), delegating the
|
end (breaking this property would break compatibility), delegating the
|
||||||
|
|
Loading…
Reference in New Issue