Skip to content

Commit aba80fa

Browse files
sobolevnZeroIntensity
authored andcommitted
pythongh-138644: Update c-api docs of PyInterpreterState about PEP-684 (pythonGH-138651)
(cherry picked from commit 4f0c267) Co-authored-by: sobolevn <[email protected]> Co-authored-by: Peter Bierma <[email protected]>
1 parent 655ad1c commit aba80fa

File tree

1 file changed

+9
-1
lines changed

1 file changed

+9
-1
lines changed

Doc/c-api/init.rst

Lines changed: 9 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1184,6 +1184,12 @@ code, or when embedding the Python interpreter:
11841184
interpreter lock is also shared by all threads, regardless of to which
11851185
interpreter they belong.
11861186
1187+
.. versionchanged:: 3.12
1188+
1189+
:pep:`684` introduced the possibility
1190+
of a :ref:`per-interpreter GIL <per-interpreter-gil>`.
1191+
See :c:func:`Py_NewInterpreterFromConfig`.
1192+
11871193
11881194
.. c:type:: PyThreadState
11891195
@@ -1875,6 +1881,8 @@ function. You can create and destroy them using the following functions:
18751881
haven't been explicitly destroyed at that point.
18761882
18771883
1884+
.. _per-interpreter-gil:
1885+
18781886
A Per-Interpreter GIL
18791887
---------------------
18801888
@@ -1886,7 +1894,7 @@ being blocked by other interpreters or blocking any others. Thus a
18861894
single Python process can truly take advantage of multiple CPU cores
18871895
when running Python code. The isolation also encourages a different
18881896
approach to concurrency than that of just using threads.
1889-
(See :pep:`554`.)
1897+
(See :pep:`554` and :pep:`684`.)
18901898
18911899
Using an isolated interpreter requires vigilance in preserving that
18921900
isolation. That especially means not sharing any objects or mutable

0 commit comments

Comments
 (0)