[Python-Dev] A little GC confusion

Kevin Jacobs jacobs@penguin.theopalgroup.com
Thu, 21 Feb 2002 08:38:42 -0500 (EST)


On Thu, 21 Feb 2002, David Abrahams wrote:
> The following extension module (AA) is a reduced example of what I'm doing
> to make extension
> classes in 2.2. I followed the examples given by typeobject.c. When I
> "import AA,pdb" I get a crash in GC. Investigating further, I see this makes
> sense: GC is enabled in class_metatype_object, yet class_type_object does
> not follow the first rule of objects whose type has GC enabled:
>
>     "The memory for the object must be allocated using PyObject_GC_New()
> or PyObject_GC_VarNew()."
>
> So, I guess the question is, how does PyBaseObject_Type (also statically
> allocated) get away with it?

I doesn't have any time to really look at your code, but I thought I'd point
out a trick that several extension modules use to protect statically
allocated type objects.  Here is the code from socketmodule.c:

/* static PyTypeObject PySocketSock_Type = {
.
.
.
        0,      /* set below */                 /* tp_alloc */
        PySocketSock_new,                       /* tp_new */
        0,      /* set below */                 /* tp_free */
};

/* buried in init_socket */
        PySocketSock_Type.tp_alloc = PyType_GenericAlloc;
        PySocketSock_Type.tp_free = _PyObject_Del;

This trick ensures that the static type object is never freed.

Also, there is a funny-looking line in your PyTypeObject:

    0, file://&PyBaseObject_Type,                     /* tp_base */

-Kevin

--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com