On Thu, Feb 3, 2022 at 7:26 AM Victor Stinner <vstin...@python.org> wrote: > In bpo-39465, I made the _PyUnicode_FromId() compatible with running > sub-interpreters in parallel (one GIL per interpreter). > > A "static" PyUnicodeObject would have to share the reference count > between sub-interpreters, whereas Py_INCREF/Py_DECREF are not > thread-safe: there is lock to prevent data races.
Yeah, if we end up not being able to safely share the global string objects between interpreters then we would move them under PyInterpreterState. Currently I'm putting them under _PyRuntimeState. Doing that might reduce the performance benefits a little, since Py_GET_GLOBAL_STRING() would have to look up the interpreter to use (or we'd have to pass it in). That doesn't seem like much of a penalty though and doesn't impact the other benefits of the change. > Is there a way to push the "immortal objects" strategy discussed in > bpo-40255? I'm planning on circling back to that next week. > The deepfreeze already pushed some functions related to > that, like _PyObject_IMMORTAL_INIT() in the internal C API. > Moreover... deepfreeze already produces "immortal" PyUnicodeObject > strings using the "ob_refcnt = 999999999" hack. Note we only set the value really high as a safety precaution since these objects are all statically allocated. Eddie Elizondo's proposal involves a number of other key points, including keeping the refcount from changing. > IMO we should decide on a strategy. Either we move towards immortal > objects (modify Py_INCREF/Py_DECREF to not modify the ref count if an > object is immortal), or we make sure that no Python is shared between > two Python interpreters. +1 The catch is that things get messier when we make some objects per-interpreter while others stay runtime-global. I'm going to write a bit more about this next week, but the best strategy will probably be to first consolidate all the global objects under _PyRuntimeState first and then move them to PyInterpreterState all at once when we can do it safely. > > I'd also like to actually get rid of _Py_IDENTIFIER(), along with > > other related API including ~14 (private) C-API functions. Dropping > > all that helps reduce maintenance costs. > > Is it required by your work on static strings, or is it more about > removing the API which would no longer be consumed by Python itself? It is definitely not required for that. Rather, we won't need it any more so we should benefit from getting rid of it. The only blocker is that some 3rd party modules are using it. > If it's not required, would it make sense to follow the PEP 387 > deprecation (mark functions as deprecated, document the deprecation, > and wait 2 releases to remove it)? If you think it's worth it. It's a private API. I'd rather work to get 3rd party modules off it and then move on sooner. -eric _______________________________________________ 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/WR33NVCSIHOMN5X7YGCL2DHNCBQGKWAU/ Code of Conduct: http://python.org/psf/codeofconduct/
