On Thu, Dec 16, 2021 at 12:00 AM Guido van Rossum <gu...@python.org> wrote: > Sam's approach is to use the lower bit of the ob_refcnt field to indicate > immortal objects. This would not work given the stable ABI (which has macros > that directly increment and decrement the ob_refcnt field). (...) we can test > for immortality by testing a single bit: > > if (o->ob_refcnt & 0x_4000_0000)
If PyQt5 or pycryptography is built with the Python 3.9 limited C API, it will use the old Py_INCREF/Py_DECREF which doesn't have special code for immortal objects. I understand that if a C extension built for an old stable ABI decrements the refcount below the limit, the object becomes mortal (can be deleted), no? I'm thinking about the case when a C extension is used in subinterpreters run in parallel (one GIL per interpreter) without any kind of locking around Py_INCREF/Py_DECREF: "data races" made "on purpose" (to not make Py_INCREF/Py_DECREF slower for the general case). Or you can think about a similar scenario with the "nogil" project. For now, I suggest to consider "subinterpreters running in parallel" and nogil use cases as special and require to build C extensions with a special option, since there are other C API changes which are incompatible with the stabl ABI anyway. * Subinterpreters running in parallel are not compatible with static type: it requires to change the ABI * nogil changes PyObject structure, Py_INCREF and Py_DECREF: it requires to change the ABI Victor -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/L5OXHXPFONRKLR3W6U46LUSUIBN4FCZQ/ Code of Conduct: http://python.org/psf/codeofconduct/
