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

[Harri Pesonen]

Skip Montanaro wrote:

>    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.
>
Yes, and there is no error if the reference count of Py_None reaches 
zero. The Py_None reference count has no meaning.

>    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.
>  
>
How can you have negative reference counts? Answer: You can't. Just 
remove the code that checks for negative reference counts. It is not 
needed. The code just gets faster again. OK, you could have it in debug 
builds, and in that case it could also check that the object was in fact 
allocated on stack.

I think that you are completely missing the point of Python's reference 
counting. :-) The idea is that when the count reaches zero, then the 
object is deallocated. But if the object was never allocated in the 
first place, why deallocate it then? That's why having empty 
none_dealloc is beautiful.

I think that PyINCREF(Py_None) is ugly, and at least it is completely 
unnecessary.

Harri