unicode: make `_PyUnicode_FromId` thread-safe in `--disable-gil` builds

[colesbury]

Feature or enhancement

The _PyUnicode_FromId(_Py_Identifier *id) function gets a Python str object (i.e., a PyUnicodeObject) from a static C string. Subsequent calls to _PyUnicode_FromId() return the same object. The initialization is not currently thread-safe without the GIL.

Mostly for my own reference, here is the implementation from nogil-3.12: colesbury/nogil-3.12@6540bf3e6a. We will want to do things a bit differently in CPython 3.13.

Linked PRs

• gh-111971: Make _PyUnicode_FromId thread-safe in --disable-gil #113489

[corona10]

@colesbury Can I take a look at this issue too?

[colesbury]

@corona10, sure. I think this requires some investigation to figure out what the right thing to do. From a quick glance, we've gotten rid of _Py_IDENTIFIER() in CPython, which is great! Since we only are keeping it to support "naught PyPI modules" we might be able to get away with just some simple locking.

[corona10]

@colesbury
You are right.
Internally, we are not using _Py_IDENTIFIER() anymore.

Since we only are keeping it to support "naught PyPI modules" we might be able to get away with just some simple locking.

For sync our implementation strategy:
So you mean that adding a mutex or lock to _Py_IDENTIFIER struct and then use the new lock from _PyUnicode_FromId side? (Allow for slight performance loss in naught PyPI modules.)

[corona10]

Now we can close this issue