Question about turning off garbage collection
tim.peters at gmail.com
Fri Oct 6 03:20:03 CEST 2006
> Question from a post to pygtk list...but it probably would be better
> answered here:
> I encountered a nasty problem with an external module conflicting with
> my python threads recently, and right now the only fix appears to be to
> turn off garbage collection while the critical code of the thread is
> running, and then turn it back on afterwards.
> Now, I don't know much about how the garbage collector works in python,
> and in order to get the thread to run without freezing, I'm wrapping the
> threaded processing function with calls to gc.disable()/gc.enable().
> So what's that going to do?
Stop the /cyclic/ garbage-collection algorithm from running for as
long as it remains disabled. Most garbage collection in Python, in
typical applications most of the time, is done by reference counting,
and /that/ can never be disabled. Reference counting alone is not
strong enough to detect trash objects in cycles (like A points to B
and B points to A and nothing else points to either; they're
unreachable trash then, but the reference count on each remains 1).
The `gc` module controls cyclic garbage collection, which is a
distinct subsystem used to find and reclaim the trash cycles reference
counting can't find on its own.
> Will calling gc.enable() put things in good shape? Will all objects created while
> the garbage collector was off now be un-collectable?
No. It has no effect except to /suspend/ running the cyclic gc
subsystem for the duration. Trash related to cycles will pile up for
the duration. That's all.
> I'm extremely wary of this solution, as I think anyone would be. I don't want a
> suddenly super-leaky app.
As above, most garbage should continue to get collected regardless.
> Comments? Suggestions? (I know, I know, avoid threads...if only I could)
Nothing wrong with threads. My only suggestion is to dig deeper into
/why/ something goes wrong when cyclic gc is enabled. That smells of
a serious bug, so that disabling cyclic gc is just papering over a
symptom of a problem that will come back to bite you later. For
example, if some piece of code in an extension module isn't
incrementing reference counts when it should, that could /fool/ cyclic
gc into believing an object is trash /while/ the extension module
believes it has a valid pointer to it. If so, that would be a serious
bug in the extension module. Enabling cyclic gc should not create
problems for any correctly written C code.
More information about the Python-list