gh-138644: Update c-api docs of PyInterpreterState about PEP-684 (#138651)

Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
This commit is contained in:
sobolevn 2025-09-08 16:44:44 +03:00 committed by GitHub
parent 59edf12705
commit 4f0c267b40
No known key found for this signature in database
GPG key ID: B5690EEEBB952194

View file

@ -1020,6 +1020,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
@ -1711,6 +1717,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
---------------------
@ -1722,7 +1730,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