From: Miss Islington (bot) <31488909+miss-islington@users.noreply.github.com> Date: Mon, 8 Sep 2025 13:52:45 +0000 (+0200) Subject: [3.13] gh-138644: Update c-api docs of `PyInterpreterState` about PEP-684 (GH-138651... X-Git-Tag: v3.13.8~95 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=7e0dfe5ba6a05de3dde8070e19e7671f95359a8b;p=thirdparty%2FPython%2Fcpython.git [3.13] gh-138644: Update c-api docs of `PyInterpreterState` about PEP-684 (GH-138651) (#138658) gh-138644: Update c-api docs of `PyInterpreterState` about PEP-684 (GH-138651) (cherry picked from commit 4f0c267b40e52b83b2e1515aa0dd74eda31ae18a) Co-authored-by: sobolevn Co-authored-by: Peter Bierma --- diff --git a/Doc/c-api/init.rst b/Doc/c-api/init.rst index 349f596a6eb9..7669d194d8b1 100644 --- 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 `. + 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