[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-capi-sig
Subject:    [capi-sig]Open questions about borrowed references
From:       Victor Stinner <vstinner () redhat ! com>
Date:       2018-09-04 11:27:16
Message-ID: CA+3bQGG1UT+g4qPp9AQ3pAkXNC8ybDLMvvDKmLv=tyONi+vXAg () mail ! gmail ! com
[Download RAW message or body]

Hi,

I'm working on the implementation of my new C API. Modifying macros to
use function calls is straighforward, but it seems like borrowed
references is a big issue. Doc/data/refcounts.dat helps to discover a
few functions and macros, but when writing a test suite on the C API,
I found many more functions: Py_TYPE(), Py_SETREF(), PyList_SetItem(),
etc.

   https://pythoncapi.readthedocs.io/bad_api.html#borrowed-references

I see borrowed references as a threat to optimizations, because we
don't know how long the caller use the return objected. For example,
if a list of numbers is specialized to store numbers as 32 bit
numbers, PyList_GetItem() has to create a temporary PyObject, but when
should we destroy this temporary PyObject? Reference counting used
"correctly" fits well with such temporary objects.

For Py_TYPE(), I like the straighfoward "Py_TYPE(obj)->tp_name" to get
the name of the object type. But is it an issue here that Py_TYPE()
returns a borrowed reference? I see an issue if the object is the only
instance of a type and there is no other reference to the type.
Example:

void test(PyObject *obj)
{
  PyTypeObject *type = Py_TYPE(obj);
  Py_DECREF(obj);
  printf("name: %s\n", type->tp_name);
}

It's posible that Py_DECREF() releases indirectly the type and so that
type becomes a dangling pointer, no?

What about Py_SETREF(): is it safe to use it? The user has to
increment manually the reference counter. API doesn't force to use
borrowed references, am I right?

Victor
_______________________________________________
capi-sig mailing list -- capi-sig@python.org
To unsubscribe send an email to capi-sig-leave@python.org
[prev in list] [next in list] [prev in thread] [next in thread]