On 8/19/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 8/19/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > On 8/19/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> > > I just fixed a bug in the new memoryview that used PyObject_DEL which
> > > caused a problem in debug mode. I had to change it to a Py_DECREF.
> > > It seems we have a lot of spellings of ways to free an object and I
> > > wonder if there are more problems lurking in there.
> > >
> > > $ cat */*.c | grep -c PyObject_Del
> > > 103
> > > $ cat */*.c | grep -c PyObject_DEL
> > > 16
> > > $ cat */*.c | grep -c PyObject_Free
> > > 16
> > > $ cat */*.c | grep -c PyObject_FREE
> > > 19
> > >
> > > I don't know how many of these are correct or incorrect.
> > >
> > > Note in Include/objimpl, the Del and Free variants are the same. I
> > > plan to get rid of one of them.
> > >
> > > #define PyObject_Del PyObject_Free
> > > #define PyObject_DEL PyObject_FREE
> > >
> > > PyObject_{MALLOC,REALLOC,FREE} depend upon whether python is compiled
> > > with debug mode, pymalloc, or not.
> > >
> > > What are the rules for when a particular API should be used (or not
> > > used) to free an object?
> >
> > If you read the comment at the top of Include/objimpl.h, it says that
> > PyObject_(New|NewVar|Del) are for object allocation while
> > PyObject_(Malloc|Realloc|Free) are just like malloc/free, but they use
> > pymalloc instead of the system malloc.
>
> Ya, I'm not talking about the distinctions/categories. They makes
> sense. The 'correctness' I was referring to (thus the rules) was when
> to use PyObject_Del vs Py_DECREF (ie, the problem with memoryview). I
> was trying to point out with the greps that the DELs/FREEs were
> infrequently used. I know there are some cases in _bsddb.c and I'm
> wondering if those are correct (there are a handful of other modules
> which also use them). The Del variants are used more in Modules while
> the Free variants are used more in the core.
Thus my suggestion to add a refcount check to _PyObject_Del. It
should only be used when the refcounts hits 0. Using it at 1 could be
allowed too, or maybe that should be a ForceDel variant?
> Changing PyObject_Del to Py_DECREF may require that more of a
> structure needs to be initialized before DECREFing, otherwise the
> dealloc might access uninitialized memory.
>
> I guess I can't really get rid of the aliases though, not without
> making the API inconsistent.
>
> > After that there are the usual performance macros.
>
> Another thing that kinda bugs me is that the 'macro' versions are not
> normally macros. In a default build (ie, with pymalloc), they are
> non-inlined function calls.
I'd much like to see the macros (other than the type casting ones)
ripped out. I doubt a performance advantage for normal non-debug uses
can be demonstrated. (Prove me wrong of course.)
The hardest part of trying to understand what to call is because of
all these macros and ifdefs.
--
Adam Olsen, aka Rhamphoryncus
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
