[Python-Dev] ob_refcnt access
ping at lfw.org
Thu Jun 24 19:29:19 CEST 1999
On Thu, 24 Jun 1999, Guido van Rossum wrote:
> > How about introducing internal macros for explicit ob_refcnt accesses
> > in the core?
> What problem does this solve?
I assume Vladimir was trying to leave the door open for further
ob_refcnt manipulation hooks later, like having objects manage
their own refcounts. Until there's an actual problem to solve
that requires this, though, i'm not sure it's necessary. Are
there obvious reasons to want to allow this?
* * *
While we're talking about refcounts and all, i've had the
argument quite successfully made to me that a reasonably
written garbage collector can be both (a) simple and (b) more
efficient than refcounting. Having spent a good number of
work days doing nothing but debugging crashes by tracing
refcounting bugs, i was easily converted into a believer
once a friend dispelled the notion that garbage collectors
were either slow or horribly complicated. I had always been
scared of them before, but less so now.
Is an incremental GC being considered for a future Python?
I've idly been pondering various tricks by which it could be
made to work with existing extension modules -- here are some
1. Keep the refcounts and let existing code do the usual
thing; introduce a new variant of PyObject_NEW that
puts an object into the "gc-able" pool rather than the
2. Have Py_DECREF and Py_INCREF just do nothing, and let
the garbage collector guess from the contents of the
structure where the pointers are. (I'm told it's
possible to do this safely, since you can only have
false positives, never false negatives.)
3. Have Py_DECREF and Py_INCREF just do nothing, and ask
the extension module to just provide (in its type
object) a table of where the pointers are in its struct.
And so on; mix and match. What are everyone's thoughts on this one?
"All models are wrong; some models are useful."
-- George Box
More information about the Python-Dev