[3.13] gh-138644: Update c-api docs of `PyInterpreterState` about PEP-684 (GH-138651...

gh-138644: Update c-api docs of `PyInterpreterState` about PEP-684 (GH-138651)
(cherry picked from commit 4f0c267b40e52b83b2e1515aa0dd74eda31ae18a)

Co-authored-by: sobolevn <mail@sobolevn.me>
Co-authored-by: Peter Bierma <zintensitydev@gmail.com>

diff --git a/Doc/c-api/init.rst b/Doc/c-api/init.rst
index 349f596a6eb9766558657d281f88f836101c3517..7669d194d8b1305cbd06d902292255e284ffcc46 100644 (file)
--- a/Doc/c-api/init.rst
+++ b/Doc/c-api/init.rst
@@ -1128,6 +1128,12 @@ code, or when embedding the Python interpreter:
    interpreter lock is also shared by all threads, regardless of to which
    interpreter they belong.
 
+   .. versionchanged:: 3.12
+
+      :pep:`684` introduced the possibility
+      of a :ref:`per-interpreter GIL <per-interpreter-gil>`.
+      See :c:func:`Py_NewInterpreterFromConfig`.
+
 
 .. c:type:: PyThreadState
 
@@ -1817,6 +1823,8 @@ function. You can create and destroy them using the following functions:
    haven't been explicitly destroyed at that point.
 
 
+.. _per-interpreter-gil:
+
 A Per-Interpreter GIL
 ---------------------
 
@@ -1828,7 +1836,7 @@ being blocked by other interpreters or blocking any others.  Thus a
 single Python process can truly take advantage of multiple CPU cores
 when running Python code.  The isolation also encourages a different
 approach to concurrency than that of just using threads.
-(See :pep:`554`.)
+(See :pep:`554` and :pep:`684`.)
 
 Using an isolated interpreter requires vigilance in preserving that
 isolation.  That especially means not sharing any objects or mutable