Some nits

This commit is contained in:
Antoine Pitrou 2017-09-08 18:13:32 +02:00
parent 6337ff8cdc
commit a8c93a3627
1 changed files with 10 additions and 4 deletions

View File

@ -143,7 +143,7 @@ An internal structure ``gc_mutex`` is added to avoid two GC runs at once:
.. code-block::
static struct {
PyThread_type_lock collecting; /* taken when collecting */
PyThread_type_lock lock; /* taken when collecting */
PyThreadState *owner; /* whichever thread is currently collecting
(NULL if no collection is taking place) */
} gc_mutex;
@ -203,6 +203,9 @@ and live inside the ``gc`` module, unless otherwise noted:
def lock_and_collect(generation=-1):
"""
Perform a collection with thread safety.
"""
me = PyThreadState_GET()
if gc_mutex.owner == me:
# reentrant GC collection request, bail out
@ -213,7 +216,7 @@ and live inside the ``gc`` module, unless otherwise noted:
gc_mutex.owner = me
try:
if generation >= 0:
return collect_generation(generation)
return collect_with_callback(generation)
else:
return collect_generations()
finally:
@ -241,6 +244,9 @@ and live inside the ``gc`` module, unless otherwise noted:
def PyGC_Malloc():
"""
Allocate a GC-enabled object.
"""
# Update allocation statistics (same code as currently, omitted for brievity)
if is_implicit_gc_desired():
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
finish.
"""
return lock_and_collect(collection)
return lock_and_collect(generation)
Discussion
@ -328,7 +334,7 @@ for example if finalizers rely on some thread-local values.
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
``gc.collect`` and ``PyGC_Collect`` actually *wait* for the collection to
end (breaking this property would break compatibility), delegating the