@@ -1128,6 +1128,12 @@ code, or when embedding the Python interpreter:
11281128 interpreter lock is also shared by all threads, regardless of to which
11291129 interpreter they belong.
11301130
1131+ .. versionchanged:: 3.12
1132+
1133+ :pep:`684` introduced the possibility
1134+ of a :ref:`per-interpreter GIL <per-interpreter-gil>`.
1135+ See :c:func:`Py_NewInterpreterFromConfig`.
1136+
11311137
11321138.. c:type:: PyThreadState
11331139
@@ -1817,6 +1823,8 @@ function. You can create and destroy them using the following functions:
18171823 haven't been explicitly destroyed at that point.
18181824
18191825
1826+ .. _per-interpreter-gil:
1827+
18201828A Per-Interpreter GIL
18211829---------------------
18221830
@@ -1828,7 +1836,7 @@ being blocked by other interpreters or blocking any others. Thus a
18281836single Python process can truly take advantage of multiple CPU cores
18291837when running Python code. The isolation also encourages a different
18301838approach to concurrency than that of just using threads.
1831- (See :pep:`554`.)
1839+ (See :pep:`554` and :pep:`684` .)
18321840
18331841Using an isolated interpreter requires vigilance in preserving that
18341842isolation. That especially means not sharing any objects or mutable