[Python-Dev] Making python C-API thread safe (try 2)
Skip Montanaro
skip at pobox.com
Wed Sep 17 10:23:45 EDT 2003
(I'm tiring rapidly of this topic. This is my last post.)
>> The current none_dealloc() will rightfully complain if myfunc() is
>> called enough times, because Py_None's reference count will go to
>> zero.
>>
Harri> Yeah, but on the other hand, the application crashes less if it
Harri> is not checked! :-)
I know you have a smiley there, however, I want the system to do its best to
crash for me and not wait until my customer has it.
Harri> There are 2001 explicit calls to Py_INCREF(Py_None) in C API
Harri> source code. These are unnecessary, but the implicit calls are of
Harri> course fine. Removing the explicit calls would make Python
Harri> slightly faster, just about enough to compensate the required
Harri> changes in deallocation mechanism as least.
How do you know that? Have you tested anything yet?
Harri> But if the reference count is negative for allocated objects,
Harri> then you already have a bug. I mean that the count is never
Harri> negative when the application works correctly. The object is
Harri> already deallocated when the count reaches zero, so checking for
Harri> negative counts is (usually) superfluous. Python gets slightly
Harri> faster if you just remove this check (from release version).
Much of the stuff in there for reference counting is there to help you when
the application doesn't work correctly.
>> That's as it should be, because any statically allocated object
>> should have a reference count of at least one.
Harri> Why? It has no meaning, because the object was never allocated,
Harri> and it can't be deallocated.
Because it is an object. Structurally and semantically it should behave the
same as all the other objects in the system.
Harri> Yeah, getting closer to that I guess. But I should not be doing
Harri> it just yet, I have other projects, but this just keeps bugging
Harri> me.
It's your itch. You have to be the one to scratch it.
Skip
More information about the Python-list
mailing list