Python 3.5.1 C API, the global available available is not destroyed when delete the module

dieter dieter at handshake.de
Wed Sep 21 01:09:45 EDT 2016


dl l <ldlchina at gmail.com> writes:
> I found the problem is resolved if call PyGC_Collect() after
> PyDict_DelItemString(). Is it expected to call PyGC_Collect() here for
> Python 3.5 which is not needed for Python 3.3?

Usually, Python uses reference counting to determine when an object
can be deleted (and then reclaims its memory).
However, reference counting cannot determine an object's obsoleteness
when it is involved in a reference cycle. To address most of these
cases, Python has an alternative way to determine object obsoleteness
based on marking the accessible objects and garbage collecting
what is inaccessible. The alternative way is what "PyGC_collect" starts.

If part of the objects where involved in a reference cycle,
you would have to call "PyGC_collect" also in Python 3.3 in order
to get a (mostly) clean memory state.
It might be, that Python 3.5 introduces more cycles than Python 3.3.
However, more likely, your code was responsible for the cycle creation
(and not Python itself). Likely, you just did not notice the problem
back for Python 3.3.

Note that "PyGC_collect", too, is not garanteed to give a memory clean
state. It does not release object cycles involving objects with
an explicite destructor ("__del__" method). Those cycles are
made available to the application (consult the documentation of the
"gc" module) which can then decide what to do about them
(e.g. break the cycles and release the associated objects).




More information about the Python-list mailing list