[Patches] GC patch 3 and 4
Vladimir Marangozov
Vladimir.Marangozov@inrialpes.fr
Thu, 29 Jun 2000 09:38:01 +0200 (CEST)
Neil Schemenauer wrote:
>
> On Thu, Jun 29, 2000 at 05:20:35AM +0200, Vladimir Marangozov wrote:
> > Neil Schemenauer wrote:
> > > The major problem I see with the current API is that PyObject_NEW
> > > and PyObject_DEL are not symmetric. When GC is enabled
> > > PyObject_NEW returns an object pointer while PyObject_DEL takes a
> > > GC pointer.
> >
> > I see. Would it make sense for PyObject_NEW to return the GC pointer ?
> > (only if the object type supports GC).
>
> I would say that's a step in the wrong direction. Since the
> PyObject_Init code has to access the object structure two
> conversions would have to be done. Also, I don't like that part
> of the implementation leaking out. If PyObject_DEL could be made
> a statement instead of an expression then something like:
>
> #ifdef WITH_CYCLE_GC
> #define PyObject_DEL(op) do { \
> if (PyObject_IS_GC(op)) { \
> PyObject_FREE(PyObject_AS_GC(op)); \
> } else { \
> PyObject_FREE(op); \
> } \
> } while (0);
> #else
> #define PyObject_DEL(op) PyObject_FREE(op)
> #endif
>
> would do the trick. The PyObject_AS_GC garbage in types could
> then be dropped. A quick look at the code indicates that
> PyObject_DEL as a statement would be okay for the types
> supporting GC. Could this work? Is it a good idea?
Yes. Go for it!
I wanted to avoid it but there's a price to pay and it seems that the
other way around is more expensive and indeed, not so clean.
OTOH, this is the genuine inlined version of PyObject_Del() which is good.
In objimpl.h, in the WITH_CYCLE_GC block, the above would look like
#ifdef WITH_CYCLE_GC
...
#undef PyObject_DEL
#define PyObject_DEL(op) ( PyObject_IS_GC(op) ? \
PyObject_FREE(PyObject_AS_GC(op)) : \
PyObject_FREE(op) )
...
#endif
--
Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252