Thanks to visit codestin.com
Credit goes to github.com

Skip to content

DOC: add free-threading release notes #27200

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.

Sign up for GitHub

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 1 commit into from
Aug 14, 2024
Merged

DOC: add free-threading release notes #27200

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
43 changes: 43 additions & 0 deletions doc/source/release/2.1.0-notes.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -101,6 +101,49 @@ been provided.
New Features
============

Preliminary Support for Free-Threaded CPython 3.13
--------------------------------------------------

CPython 3.13 will be available as an experimental free-threaded build. See
https://py-free-threading.github.io, `PEP 703
<https://peps.python.org/pep-0703/>`_ and the `CPython 3.13 release notes
<https://docs.python.org/3.13/whatsnew/3.13.html#free-threaded-cpython>`_ for
more detail about free-threaded Python.

NumPy 2.1 has preliminary support for the free-threaded build of CPython
3.13. This support was enabled by fixing a number of C thread-safety issues in
NumPy. Before NumPy 2.1, NumPy used a large number of C global static variables
to store runtime caches and other state. We have either refactored to avoid the
need for global state, converted the global state to thread-local state, or
added locking.

Support for free-threaded Python does not mean that NumPy is thread
safe. Read-only shared access to ndarray should be safe. NumPy exposes shared
mutable state and we have not added any locking to the array object itself to
serialize access to shared state. Care must be taken in user code to avoid
races if you would like to mutate the same array in multiple threads. It is
certainly possible to crash NumPy by mutating an array simultaneously in
multiple threads, for example by calling a ufunc and the ``resize`` method
simultaneously. For now our guidance is: "don't do that". In the future we would
like to provide stronger guarantees.

Object arrays in particular need special care, since the GIL
previously provided locking for object array access and no longer does. See
`Issue #27199 <https://github.com/numpy/numpy/issues/27199>`_ for more
information about object arrays in the free-threaded build.

If you are interested in free-threaded Python, for example because you have a
multiprocessing-based workflow that you are interested in running with Python
threads, we encourage testing and experimentation.

If you run into problems that you suspect are because of NumPy, please `open an
issue <https://github.com/numpy/numpy/issues/new/choose>`_, checking first if
the bug also occurs in the "regular" non-free-threaded CPython 3.13 build. Many
threading bugs can also occur in code that releases the GIL; disabling the GIL
only makes it easier to hit threading bugs.

(`gh-26157 <https://github.com/numpy/numpy/issues/26157#issuecomment-2233864940>`__)

* ``numpy.reshape`` and ``numpy.ndarray.reshape`` now support ``shape`` and
``copy`` arguments.

Expand Down