Question about turning off garbage collection

[David Hirschfield]

Thanks for the great response!

I'm positive there's something extremely funky going on underneath 
that's causing the problem when cyclic garbage collection is turned on. 
Unfortunately I haven't got access to the code for the module that 
appears to be causing the trouble.

It really appears to be some incompatibility between python threads, 
pygtk and the database access module I'm using...and it's a royal pain. 
Fortunately your response makes me comfortable that I can at least turn 
off the gc without creating a leaky mess. When I have a chance I'll try 
to create a test case that clearly demonstrates the problem so I can get 
the authors of the modules to find the real problem.

Thanks,
-Dave

Tim Peters wrote:
> [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.
>   

-- 
Presenting:
mediocre nebula.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20061005/fa063de1/attachment.html>