Bug report
On Windows, the Py_GIL_DISABLED macro is not defined when building C API extensions with the free-threaded build of CPython 3.13 (i.e., --disable-gil). Now that biased reference counting (6dfb8fe) landed, this leads to incorrect/failed compilation of extensions on Windows 1. The problem does not occur on Linux/macOS and other ./configure based builds because that build system defines the Py_NOGIL macro as part of pyconfig.h. On Windows, Py_GIL_DISABLED instead defined as a pre-processor definition in pyproject.props, but that's used by C-API extensions.
Among other problems, this leads to test_peg_generator failing on the nogil Windows buildbot (example failure).
I can think of two possible approaches to fixing this:
- Modify setuptools (maybe setuptools.distutils?) to define
Py_GIL_DISABLED when invoking the compiler if sysconfig.get_config_var("Py_NOGIL") is True.
- In the CPython Windows build, generate a header file defining/undefing
Py_GIL_DISABLED depending on if the build is invoked with --disable-gil or not.
The first option seems a little more straightforward to me, but there is a risk that we might encounter this same issue across multiple extension build systems. The second option seems like it would more robustly address this issue.
Linked PRs
Bug report
On Windows, the
Py_GIL_DISABLEDmacro is not defined when building C API extensions with the free-threaded build of CPython 3.13 (i.e.,--disable-gil). Now that biased reference counting (6dfb8fe) landed, this leads to incorrect/failed compilation of extensions on Windows 1. The problem does not occur on Linux/macOS and other./configurebased builds because that build system defines thePy_NOGILmacro as part ofpyconfig.h. On Windows,Py_GIL_DISABLEDinstead defined as a pre-processor definition inpyproject.props, but that's used by C-API extensions.Among other problems, this leads to
test_peg_generatorfailing on the nogil Windows buildbot (example failure).I can think of two possible approaches to fixing this:
Py_GIL_DISABLEDwhen invoking the compiler ifsysconfig.get_config_var("Py_NOGIL")isTrue.Py_GIL_DISABLEDdepending on if the build is invoked with--disable-gilor not.The first option seems a little more straightforward to me, but there is a risk that we might encounter this same issue across multiple extension build systems. The second option seems like it would more robustly address this issue.
Linked PRs
Footnotes
Modules built as part of the CPython build (i.e., standard library modules) still work ↩