[Python-Dev] Making python C-API thread safe (try 2)

Skip Montanaro skip at pobox.com
Tue Sep 16 21:22:13 CEST 2003

    Harri> Py_None is special because it is shared between all interpreters, it is 
    Harri> global. Py_None is defined as:


    Harri> From the above we see that when Py_None reference count reaches
    Harri> zero, a destructor none_dealloc is called.


    Harri> This makes no sense at all. Why Py_FatalError? It would be better
    Harri> to have

    Harri> static void
    Harri> none_dealloc(PyObject* ignore)
    Harri> {
    Harri> }

Actually, it makes perfect sense.  The reference count of Py_None is never
supposed to reach zero.  If that happens it's because you have a bug (too
many Py_DECREFs or not enouch Py_INCREFs).  Your version of none_dealloc
silently masks the error.

    Harri> so that it is not necessary to call Py_INCREF(Py_None)
    Harri> Py_DECREF(Py_None) at all. Guess how many times these are called
    Harri> in Python C API? Py_INCREF is called 2001 times and Py_DECREF two
    Harri> times.

You mean how many places does Py_(IN|DE)CREF(Py_None) appear?  Note that in
most situations the interpreter itself calls Py_DECREF(<return value>) for
you.  You just can't tell that "<return value>" is Py_None using a static
scan of the C source code.

    Harri> By changing the way how Py_None is freed (by doing nothing)
    Harri> Python would get simpler and faster.  

I think you are completely missing the point of Python's reference
counting.  Py_None is nothing special except for the fact that it is not
allocated on the stack.  In fact, if you removed all the INCREFs and
DECREFs I think you'd have to special-case the code which detects negative
reference counts.  Py_None's reference count would quickly go negative and
instead of the normal reference counting dance you'd always be calling the
error function which handles negative ref counts.  It would always have to
compare its argument object with Py_None to make sure it wasn't complaining
about the now-special Py_None object.


More information about the Python-list mailing list