<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Thanks for the great response!<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks,<br>
-Dave<br>
<br>
Tim Peters wrote:
<blockquote
cite="mid1f7befae0610051820r6defed8es77d206a57af8a6eb@mail.gmail.com"
type="cite">
<pre wrap="">[David Hirschfield]
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">Will calling gc.enable() put things in good shape? Will all objects created while
the garbage collector was off now be un-collectable?
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">I'm extremely wary of this solution, as I think anyone would be. I don't want a
suddenly super-leaky app.
</pre>
</blockquote>
<pre wrap=""><!---->
As above, most garbage should continue to get collected regardless.
</pre>
<blockquote type="cite">
<pre wrap="">Comments? Suggestions? (I know, I know, avoid threads...if only I could)
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Presenting:
mediocre nebula.
</pre>
</body>
</html>