[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. -- http://mail.python.org/mailman/listinfo/python-list
