[Python-Dev] GC and ExtensionClass workaround (original) (raw)

[Python-Dev] GC and ExtensionClass - a summary of the problem and a workaround

M.-A. Lemburg mal@lemburg.com
Thu, 17 May 2001 09:09:38 +0200

skip@pobox.com wrote:

mal> I wonder how the GC collector could "see" the type object before it mal> has been initialized... since PyGtkTreeSortableType is a static C mal> array and not a known PyObject until you add it to some Python mal> dictionary as type object or use it for creating instances, it mal> seems strange that the GC collector can reach out for it and get mal> hit by the fact that it is not yet properly initialized. It is actually PyGtkWidgetType that is not yet initialized when it is placed in the bases tuple for one of its subclasses. GC traverses that tuple, then dives into each element. It hits the PyGtkWidgetType object, whose obtype field has not yet been initialized. The actual object whose bases tuple is being traversed is (in all the crashes I encountered), GdkDragContext. The ordering of the registration calls could perhaps be reordered. Currently GdkDragContext is patched up before GtkWidget, its base class. This code is generated by James Henstridge's wrapper code generator, so perhaps he can maintain the necessary class hierarchy relationships and insure that base classes are initialized before their subclasses.

Wouldn't it be easier to simply set the ob_type fields right at the start of the initGtk() function ? This is what I do for all my extensions and I've never seen any problems with it.

-- Marc-Andre Lemburg

Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/