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 lock is also shared by all threads, regardless of to which
interpreter they belong. 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 .. 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. haven't been explicitly destroyed at that point.
.. _per-interpreter-gil:
A 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 single Python process can truly take advantage of multiple CPU cores
when running Python code. The isolation also encourages a different when running Python code. The isolation also encourages a different
approach to concurrency than that of just using threads. 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 Using an isolated interpreter requires vigilance in preserving that
isolation. That especially means not sharing any objects or mutable isolation. That especially means not sharing any objects or mutable