On Wed, Feb 2, 2022 at 11:43 PM Eric Snow <ericsnowcurrently@gmail.com> wrote:
> My plan is to replace our use of _Py_IDENTIFIER() with statically
> initialized string objects (as fields under _PyRuntimeState). That
> involves the following:
>
> * add a PyUnicodeObject field (not a pointer) to _PyRuntimeState for
> each string that currently uses _Py_IDENTIFIER() (or
> _Py_static_string())
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.
Is there a way to push the "immortal objects" strategy discussed in
bpo-40255? 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.
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.
Either we come to an agreement as a group (for against the concept and then how to do it), or if there's a stalemate it goes to the SC (with potentially a PEP to properly explain the nuances of the proposed solution).
-Brett
> 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?
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)?
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/FFQ6N7K2BHG37JVFOACIEZLTKH43NV3L/
Code of Conduct: http://python.org/psf/codeofconduct/