[capi-sig]Re: Open questions about borrowed references
On 2018-09-05 13:49, Petr Viktorin wrote:
I'm not at a computer right now, but AFAIK if <class int>'s refcount drops to zero, we still try to deallocate it, and that causes an assertion and terminates the interpreter.
You're right but that's besides the original point. If code uses refcounting correctly (regardless of using an "old" or "new" API), then the class int will never be deallocated.
On Wed, Sep 5, 2018, 13:55 Jeroen Demeyer J.Demeyer@ugent.be wrote:
On 2018-09-05 13:49, Petr Viktorin wrote:
I'm not at a computer right now, but AFAIK if <class int>'s refcount drops to zero, we still try to deallocate it, and that causes an assertion and terminates the interpreter.
You're right but that's besides the original point. If code uses refcounting correctly (regardless of using an "old" or "new" API), then the class int will never be deallocated.
Right you are. What I was solving is not an issue.
Allocating/deallocating tagged-pointer "small ints" doesn't need to incref/decref the type at all. Conceptually, their reference to the type object is borrowed from the interpreter itself (and the interpreter already promises not to release it while any code is running). The caller of PY_Type then borrows that reference again.
capi-sig mailing list -- capi-sig@python.org To unsubscribe send an email to capi-sig-leave@python.org
Le mer. 5 sept. 2018 à 13:56, Jeroen Demeyer J.Demeyer@ugent.be a écrit :
On 2018-09-05 13:49, Petr Viktorin wrote:
I'm not at a computer right now, but AFAIK if <class int>'s refcount drops to zero, we still try to deallocate it, and that causes an assertion and terminates the interpreter.
You're right but that's besides the original point. If code uses refcounting correctly (regardless of using an "old" or "new" API), then the class int will never be deallocated.
In an previous email, I designed an example where the reference count of a type reachs zero and the type is destroyed, and so Py_TYPE() result becomes a dangling pointer.
"Using reference counter correctly" is a wide topic. My example looks like:
PyObject *obj = create_object(); PyTypeObject *type = Py_TYPE(obj); Py_DECREF(obj); /* ... */ /* type is now a dangling pointer */
Do you consider that this example uses reference counting "correctly"?
Victor
On Wed, Sep 5, 2018 at 11:21 PM Victor Stinner vstinner@redhat.com wrote:
In an previous email, I designed an example where the reference count of a type reachs zero and the type is destroyed, and so Py_TYPE() result becomes a dangling pointer.
"Using reference counter correctly" is a wide topic. My example looks like:
PyObject *obj = create_object(); PyTypeObject *type = Py_TYPE(obj); Py_DECREF(obj); /* ... */ /* type is now a dangling pointer */
Do you consider that this example uses reference counting "correctly"?
To me, a "dangling pointer" is one that refers to memory that has been freed. Here the type is only a dangling pointer IFF obj was the only object existing of that type, so Py_DECREF(obj) recursively deleted the type as well.
Except for this very rare case, type continues to point to a valid object. The reference count for that type is now off by one. But as others have observed before, this is a very contrived example. I've never seen code like this in a C extension module.
It don't think it is worth forcing every C extension module to be rewritten, and incur a performance hit, to eliminate a rare bug from badly written code.
--
cheers,
Hugh Fisher
participants (4)
-
Hugh Fisher -
Jeroen Demeyer -
Petr Viktorin -
Victor Stinner