A few thoughts:

• Yes, if the owning thread calls Py_INCREF() concurrently with another thread trying to immortalize the object, that will result in a race condition
• _Py_SetImmortal() is not public and I don't think we should make it public (at least not in 3.13)
• The check that the caller is the owning thread is conservative. It's also safe to immortalize objects in certain other cases, such as during a stop-the-world event.

I would be hesitant to add an assertion to _Py_SetImmortal() because we call it from a number of places where we already know we are in a bad state, like none_dealloc.

The only call I've seen that concerns me is in _PyUnicode_InternInPlace(). In the free-threaded builds, we should probably only immortalize the string if it is owned by the current thread.

@colesbury thanks for the reply. This makes sense. I had thought this is more externally reachable.

I think you could make it concurrency safe by borrowing a third bit from ob_ref_shared to represent Immortal.

I think you could make it concurrency safe by borrowing a third bit from ob_ref_shared to represent Immortal.

Yeah, that would address concurrency safety, but using ob_ref_local serves two other purposes:

1. It let's us make ob_ref_local 32-bits without having to worry about overflow, because the immortal value is UINT32_MAX.
2. It makes the common cases for Py_INCREF and Py_DECREF faster because we only need to access ob_tid and ob_ref_local.