It isn't possible to temporarily resurrect objects safely in the Py3.15t limited API

Bug report

Bug description:

In Cython we do something like

Py_SET_REFCNT(o, Py_REFCNT(o) + 1);
// Run user implemented deallocation code
Py_SET_REFCNT(o, Py_REFCNT(o) - 1);

The reason for this is that we don't want any refcounting (e.g. of temps) within the user code to accidentally trigger a recursive call to dealloc (the user code really shouldn't resurrect the object and it's their own problem if they do, but it is reasonable for it to generate temporaries, which may well be out of their control anyway).

This turns out not to be thread-safe in the freethreaded build because it makes TryIncRef succeed. Outside the limited API it's possible to fix by manual access to the reference count, but obviously not inside the limited API.

It would be nice to have a way of to avoid this.

• Most convenient would be to properly access _PyObject_ResurrectStart and _PyObject_ResurrectEnd.
• The other thing that could work is some way to defer the deallocation until the next GC cycle (when I think any TryIncRefs would have fall out of scope anyway). I suspect I could manually arrange to do that, although it feels fragile, possibly relies on the GC being single-threaded, and which I haven't tested (so may not work...)

CPython versions tested on:

3.15

Operating systems tested on:

No response

Bắt đầu bằng việc xem xét bề mặt limited-API liên quan đến việc hồi sinh refcount và hành vi TryIncRef trong chế độ free-threaded được mô tả ở đây, sau đó so sánh với _PyObject_ResurrectStart và _PyObject_ResurrectEnd cũng như Cython issue #7769. Hoàn thành khi có một cơ chế limited-API được định nghĩa và thread-safe, tránh việc hồi sinh tạm thời không an toàn trong mã giải phóng của người dùng.