Repository navigation
unicode: make _PyUnicode_FromId thread-safe in --disable-gil builds #111971
Description
Activity
- changed the title
[-]Make `_PyUnicode_FromId` thread-safe in `--disable-gil` builds[/-][+]unicode: make `_PyUnicode_FromId` thread-safe in `--disable-gil` builds[/+]on Nov 10, 2023 @colesbury Can I take a look at this issue too?
@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.Reacted by Donghee Na@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.)Now we can close this issue
Feature or enhancement
The
_PyUnicode_FromId(_Py_Identifier *id)function gets a Pythonstrobject (i.e., aPyUnicodeObject) 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