Feat/enable free threaded python - #213
Conversation
There was a problem hiding this comment.
Pull request overview
This PR adds initial support for CPython’s free-threaded (GIL-disabled) builds in mkl-service, and (as a prerequisite / in anticipation of PR #174) migrates the build and packaging flow from setuptools/setup.py to meson-python across pip/CI/conda recipes.
Changes:
- Enable free-threading compatibility in the Cython extension and declare the
_mklinitC extension as GIL-independent for free-threaded interpreters. - Switch to
meson-python(meson.build,pyproject.toml) and removesetup.py. - Update CI workflows and conda recipes to build via PEP 517 / Meson and expand Python coverage to 3.14.
Reviewed changes
Copilot reviewed 19 out of 19 changed files in this pull request and generated 7 comments.
Show a summary per file
| File | Description |
|---|---|
| setup.py | Removed legacy setuptools build script. |
| pyproject.toml | Switch build backend to mesonpy and update build requirements. |
| meson.build | New Meson build defining _mklinit and _py_mkl_service extension builds and install layout. |
| mkl/_py_mkl_service.pyx | Mark Cython extension as free-threading compatible. |
| mkl/_mklinitmodule.c | Declare module GIL usage as “not used” on free-threaded builds. |
| README.md | Add source build instructions for Meson/PEP517 flow. |
| AGENTS.md | Update repo-level build/CI documentation to Meson + new workflows. |
| mkl/AGENTS.md | Update Cython wrapper file naming references. |
| .github/workflows/build-with-clang.yml | Update CI build steps for Meson/PEP517 and Python 3.14. |
| .github/workflows/build-with-standard-clang.yml | New workflow to build/test with system clang. |
| .github/workflows/build_pip.yml | New workflow to validate pip editable build + tests via conda env. |
| conda-recipe/meta.yaml | Update host deps for Meson/PEP517 and remove python-gil constraints. |
| conda-recipe/build.sh | Build via python -m build instead of setup.py; clean build dir. |
| conda-recipe/bld.bat | Build via python -m build instead of setup.py. |
| conda-recipe-cf/meta.yaml | Update host deps for Meson/PEP517 and remove python-gil constraints. |
| conda-recipe-cf/build.sh | Build/install via pip (PEP517) instead of setup.py. |
| conda-recipe-cf/bld.bat | Build/install via pip (PEP517) instead of setup.py. |
| .github/copilot-instructions.md | Update API-contract file reference to _py_mkl_service.pyx. |
| .github/AGENTS.md | Document newly added workflows. |
Comments suppressed due to low confidence (1)
mkl/_py_mkl_service.pyx:28
- Free-threading support is being enabled here, but there’s no corresponding test ensuring the package imports/operates correctly under a free-threaded (GIL-disabled) Python build (e.g., that importing
mkldoes not re-enable the GIL and basic API calls still work). Adding a small conditional test inmkl/tests/test_mkl_service.pywould help prevent regressions.
|
the copilot review comments are basically on the meson python PR #174 |
| @@ -55,7 +55,7 @@ jobs: | |||
|
|
|||
There was a problem hiding this comment.
Need to extend strategy matrix for GitHub workflows to validate 3.14t also
There was a problem hiding this comment.
Added "3.14t" to the matrices
There was a problem hiding this comment.
need to add to the conda package workflow too, which requires more robust strategy. See approach in dpctl
There was a problem hiding this comment.
I followed the changes in dpctl and updated it for mkl-service
Summary
Enable free threading support for
mkl-serviceDepends on gh-174 (meson-python migration), which is now merged.
Free-threading declarations
Two declarations tell the interpreter the extensions are safe without the GIL:
mkl/_py_mkl_service.pyxnow sets# cython: freethreading_compatible=True.mkl/_mklinitmodule.ccallsPyUnstable_Module_SetGIL(m, Py_MOD_GIL_NOT_USED)in
PyInit__mklinit, guarded by#ifdef Py_GIL_DISABLEDso it is a no-op onregular builds.
Cython 3.1.0 floor
freethreading_compatiblewas introduced in Cython 3.1.0. Verified against thesources: the directive is absent from
Cython/Compiler/Options.pyin 3.0.12(the final 3.0.x) and present in 3.1.0. On older releases the directive is an
unrecognised option and the declaration silently does not happen.
The floor is applied consistently in
pyproject.toml, both conda recipes, allpip-based workflows, and the README build instructions. This is a floor, not a cap.