This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: [subinterpreters] Unicode interned strings must not be shared between interpreters
Type: Stage:
Components: Subinterpreters Versions: Python 3.11
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: eric.snow, petr.viktorin, vstinner
Priority: normal Keywords:

Created on 2022-01-06 15:21 by vstinner, last changed 2022-04-11 14:59 by admin.

Messages (2)
msg409860 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2022-01-06 15:21
My commit ea251806b8dffff11b30d2182af1e589caf88acf made Unicode interned strings per interpreter to avoid accessing the same Python object from two different interpreters, to avoid race conditions on its reference count.

Problem: the change introduced the bpo-46006 regression in _PyUnicode_EqualToASCIIId() and type update_slot() functions which make the assumption that if two strings are interned and their pointers are not equal: these strings are not equal.

I proposed PR 30123 to fix these two functions, but then questions have been asked about the overall goal, running multiple Python interpreters in parallel in the same process (bpo-40512):

bpo-46006 was blocking the Python 3.11.0a4 release, Python 3.10 was affected and there were more and more affected projects:

* jep:
* mod_wsgi:
* weechat-matrix:
* Fedora issue about mod_wsgi and weechat-matrix:

So I decided to just revert the change on interned strings:

* main branch: commit 35d6540c904ef07b8602ff014e520603f84b5886
* 3.10 branch: commit 72c260cf0c71eb01eb13100b751e9d5007d00b70 (with changes to keep the ABI backward compatibility)

These interned strings are preventing again to run multiple interpreters in parallel, two subinterpreters must not access the same Python object: see bpo-40533.

I suggest to write a PEP to explain the rationale, and reapply my commit ea251806b8dffff11b30d2182af1e589caf88acf with PR 30123.
msg410197 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2022-01-10 10:50
Another proposed alternative is to make these immortal, and share them.

There were some discussions about this, but no PEP to capture the pros/cons of the alternatives and the decision.
Date User Action Args
2022-04-11 14:59:54adminsetgithub: 90441
2022-01-10 10:50:20petr.viktorinsetnosy: + petr.viktorin
messages: + msg410197
2022-01-06 15:21:29vstinnersetnosy: + eric.snow
2022-01-06 15:21:22vstinnercreate