Skip to content

Enable free threading support - #255

Open
vchamarthi wants to merge 7 commits into
IntelPython:mainfrom
vchamarthi:feat/free-threaded-python
Open

Enable free threading support#255
vchamarthi wants to merge 7 commits into
IntelPython:mainfrom
vchamarthi:feat/free-threaded-python

Conversation

@vchamarthi

Copy link
Copy Markdown
Contributor

Adds free-threaded (GIL-disabled) CPython 3.14t support to mkl_umath by declaring both the Cython extension and the hand-written _ufuncs C extension as free-threading compatible, aligning build tooling requirements, and expanding CI/conda packaging to cover both CPython 3.14 (GIL) and 3.14t (free-threaded) variants.

Changes:

  • Mark mkl_umath/src/_patch_numpy.pyx as freethreading_compatible for Cython, and declare Py_MOD_GIL_NOT_USED in the _ufuncs C extension (ufuncsmodule.c) so importing either module no longer re-enables the GIL.
  • Pin Cython to >=3.1.0 across build/packaging (pyproject.toml, both conda recipes, AGENTS.md, README.md).
  • Update conda recipes to require cython >=3.1.0 and remove python-gil pins.
  • Extend conda/pip CI matrices to build/test CPython 3.14 cp314 and cp314t variants and adjust cache/artifact naming accordingly.
  • Add concurrency tests covering multi-threaded ufunc execution and patch/restore state, plus a regression guard asserting the GIL stays disabled on import.

Comment on lines +34 to +37
# Oversubscription: MKL spawns its own thread pool per calling thread, so
# running MKL VM calls from many Python threads concurrently can spawn
# far more OS threads than cores. Cap it before mkl_umath/MKL initialize.
os.environ.setdefault("MKL_NUM_THREADS", "1")

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Can you verify that this actually works, and that the MKL thread count is actually capped? It's not clear to me that MKL won't be initialized already in some environments, either, especially ones with mkl-service, etc.

I think it would be best to avoid trying to set environment variables this way if possible, too, as it can be unreliable, but as long as we verify it should be ok

@antonwolfy antonwolfy added this to the 0.6.0 release milestone Aug 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants