Skip to content

Docs: add whatsnew for free-threading #118679

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
May 7, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
46 changes: 46 additions & 0 deletions Doc/whatsnew/3.13.rst
Original file line number Diff line number Diff line change
Expand Up @@ -99,6 +99,12 @@ New typing features:
* :pep:`742`: :data:`typing.TypeIs` was added, providing more intuitive
type narrowing behavior.

Free-threading:

* :pep:`703`: CPython 3.13 has experimental support for running with the
:term:`global interpreter lock` disabled when built with ``--disable-gil``.
See :ref:`Free-threaded CPython <free-threaded-cpython>` for more details.

New Features
============

Expand Down Expand Up @@ -1052,6 +1058,46 @@ See :pep:`744` for more details.
Tier 2 IR by Mark Shannon and Guido van Rossum.
Tier 2 optimizer by Ken Jin.)

.. _free-threaded-cpython:

Free-threaded CPython
=====================

CPython will run with the :term:`global interpreter lock` (GIL) disabled when
configured using the ``--disable-gil`` option at build time. This is an
experimental feature and therefore isn't used by default. Users need to
either compile their own interpreter, or install one of the experimental
builds that are marked as *free-threaded*.

Free-threaded execution allows for full utilization of the available
processing power by running threads in parallel on available CPU cores.
While not all software will benefit from this automatically, programs
designed with threading in mind will run faster on multicore hardware.

Work is still ongoing: expect some bugs and a substantial single-threaded
performance hit.

The free-threaded build still supports optionally running with GIL enabled at
runtime using the environment variable :envvar:`PYTHON_GIL` or the command line
option :option:`-X gil`.

* Use :func:`!sys._is_gil_enabled` to determine if the :term:`GIL` is enabled.

* Use ``sysconfig.get_config_var("Py_GIL_DISABLED")`` to identify CPython
builds configured with ``--disable-gil``.
Comment on lines +1084 to +1087
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not clear from this why we need both APIs. I'm guessing it's because even when built with --disable-gil the GIL may be dynamically re-enabled?


C-API extensions need to be built specifically for the free-threaded build.

* Extensions that support running with the :term:`GIL` disabled should use
the :c:data:`Py_mod_gil` slot. Extensions using single-phase init should use
:c:func:`PyUnstable_Module_SetGIL` to indicate whether they support running
with the GIL disabled. Importing C extensions that don't use these mechanisms
will cause the GIL to be enabled unless the GIL was explicitly disabled with
the :envvar:`PYTHON_GIL` environment variable or the :option:`-X gil=0`
option.

* pip 24.1b1 or newer is required to install packages with C extensions in the
free-threaded build.


Deprecated
Expand Down