Question about turning off garbage collection

[Tim Peters]

[David Hirschfield]
> 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.