GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Py_GIL_DISABLED not defined in "free-threaded" Windows C-API extensions · Issue #111650 · python/cpython

Py_GIL_DISABLED not defined in "free-threaded" Windows C-API extensions  #111650

New issue
Copy link
New issue
Copy link
Closed
Closed
Py_GIL_DISABLED not defined in "free-threaded" Windows C-API extensions #111650
Copy link
Assignees
zooba
Labels
3.13only security fixesonly security fixestopic-free-threadingtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

Description

@colesbury
colesbury
opened on Nov 2, 2023
Issue body actions

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:

  1. Modify setuptools (maybe setuptools.distutils?) to define Py_GIL_DISABLED when invoking the compiler if sysconfig.get_config_var("Py_NOGIL") is True.
  2. 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

  • gh-111650: Generate pyconfig.h on Windows #112179
  • gh-111650: Ensure pyconfig.h includes Py_GIL_DISABLED on Windows #112778

Footnotes

  1. Modules built as part of the CPython build (i.e., standard library modules) still work ↩

Activity

Next
  1. colesbury
    added
    type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
    3.13only security fixesonly security fixes
    topic-free-threading
    on Nov 2, 2023
  2. colesbury commented on Nov 2, 2023

    @colesbury
    colesbury
    on Nov 2, 2023
    ContributorAuthor
    More actions

    @zooba, I'd appreciate your feedback and suggestions about the best way to make sure that Windows C API extensions have Py_NOGIL defined when building with the free-threaded (--disable-gil) 3.13 builds.

  3. corona10 commented on Nov 2, 2023

    @corona10
    corona10
    on Nov 2, 2023
    Member
    More actions

    Among other problems, this leads to test_peg_generator failing on the nogil Windows buildbot (example failure).

    I was curious about how GHA passed the test, but I noticed that it was skipped from the GHA..
    https://github.com/python/cpython/actions/runs/6695685454/job/18191835485

    0:16:09 load avg: 10.69 [405/469/1] test_peg_generator skipped (resource denied) -- running (1): test_importlib (42.1 sec)
    test_peg_generator skipped -- Use of the 'cpu' resource not enabled
    
    Reacted by Sam Gross
  4. zooba commented on Nov 2, 2023

    @zooba
    zooba
    on Nov 2, 2023
    Member
    More actions

    I think we probably need to start modifying pyconfig.h at some stage in the build process. Eventually we should get an improved sysconfig [alternative] that can include the flag, but until then I don't think we want to make modifications in every build backend that's out there, nor do we want to force them to launch the target interpreter in order to get the right settings (which prevents cross-compilation, for example).

    I'm not sure how best to do it though. Probably the ideal looks like:

    • copy/patch pyconfig.h and write it to $(IntDir) (not back into the source tree)
    • do rest of build referencing that directory instead of PC\
    • copy patched pyconfig.h into $(OutDir)
    • make sure Tools/msi and PC/layout pull it from the output directory and not the sources
    • make sure the build in release-tools does the same (though I think it should happen automatically with the previous changes)

    We shouldn't have to patch anything in the stdlib that finds the header, I'm pretty sure they were only in distutils. And an install layout should have it end up in the Include directory if Tools/msi and PC/layout are updated.

    So there's a lot of moving parts, plus we need to figure out the best way to template the header so it can be modified as part of the build. There's not really anything built into our build system for this yet.

    Reacted by Sam Gross
    Reacted by stonebig
  5. colesbury commented on Nov 16, 2023

    @colesbury
    colesbury
    on Nov 16, 2023
    ContributorAuthor
    More actions

    Hi @zooba, I started implementing this and ran into a few issues. Not having a pyconfig.h in PC or Include breaks setuptools. The install layout can place the generated pyconfig.h in the installed Include directory, but you can also run pip directly from the CPython source directory without the installer. It seems like we'll run into fewer issues if we place the generated pyconfig.h in the PC directory.

  6. colesbury
    added 6 commits that reference this issue on Nov 16, 2023

    pythongh-111650: Generate pyconfig.h on Windows

    d282ad1

    pythongh-111650: Generate pyconfig.h on Windows

    5515cdf

    pythongh-111650: Generate pyconfig.h on Windows

    10ceec5

    pythongh-111650: Generate pyconfig.h on Windows

    e4c3520

    pythongh-111650: Generate pyconfig.h on Windows

    912e169

    pythongh-111650: Generate pyconfig.h on Windows

    6585ab1
  7. zooba commented on Nov 29, 2023

    @zooba
    zooba
    on Nov 29, 2023
    Member
    More actions

    Left a few suggestions on the draft PR - in short:

    • I prefer Include\pyconfig.h over PC\pyconfig.h, and I suspect/hope every other tool will, too.
    • setuptools is definitely going to need an update of some kind here, at least for running within build directories (likely in code taken from distutils). Regular installs shouldn't have any issue. I think we should do the setuptools update in parallel, and not try to make their older versions work.
    • As neat as the PowerShell script is, we already assume a bootstrap Python is available, so it may as well be a Python script
  8. colesbury commented on Nov 29, 2023

    @colesbury
    colesbury
    on Nov 29, 2023
    ContributorAuthor
    More actions

    POSIX places the generated pyconfig.h in the root directory, not in Include. Placing it in Include/pyconfig.h is would be a third location for tools to handle, breaks setuptools (and possibly other build tools), and does not get us any closer to unifying the builds.

    setuptools is definitely going to need an update of some kind here...

    If we don't move pyconfig.h, what update will setuptools need?

    As neat as the PowerShell script is, we already assume a bootstrap Python is available, so it may as well be a Python script

    Sure - I'll convert the script to Python.

  9. 1 remaining item

  10. colesbury commented on Dec 4, 2023

    @colesbury
    colesbury
    on Dec 4, 2023
    ContributorAuthor
    More actions

    I don't know how to implement what you are asking for and I've already spent a few days on this, so I'm going to defer this and come back to it later.

    Reacted by Steve Dower
  11. zooba
    self-assigned this
    on Dec 5, 2023
  12. zooba commented on Dec 5, 2023

    @zooba
    zooba
    on Dec 5, 2023
    Member
    More actions

    I'll get it figured out. Chances are I'm going to have to do all the integration into the release process anyway, so I may as well go end-to-end.

  13. zooba
    added a commit that references this issue on Dec 5, 2023

    pythongh-111650: Ensure pyconfig.h includes PY_GIL_DISABLED on Windows

    4feb2ce
  14. colesbury
    changed the title [-]Py_NOGIL not defined in "free-threaded" Windows C-API extensions [/-] [+]Py_GIL_DISABLED not defined in "free-threaded" Windows C-API extensions [/+] on Dec 6, 2023
  15. zooba
    added 3 commits that reference this issue on Dec 6, 2023

    Merge remote-tracking branch 'upstream/main' into pythongh-111650

    094ccd9

    Merge remote-tracking branch 'upstream/main' into pythongh-111650

    85811ea

    gh-111650: Ensure pyconfig.h includes Py_GIL_DISABLED on Windows (GH-…

    79dad03
  16. ambv commented on Jan 7, 2024

    @ambv
    ambv
    on Jan 7, 2024
    Contributor
    More actions

    Is there anything left to do here?

  17. ambv
    closed this as completedon Jan 7, 2024
  18. aisk
    added a commit that references this issue on Feb 11, 2024

    pythongh-111650: Ensure pyconfig.h includes Py_GIL_DISABLED on Windows (

    aa326a6
  19. Glyphack
    added a commit that references this issue on Sep 2, 2024

    pythongh-111650: Ensure pyconfig.h includes Py_GIL_DISABLED on Windows (

    82fcdcc
  20. cvijdea-bd
    added 2 commits that reference this issue on Sep 27, 2024

    Define Py_GIL_DISABLED macro on Windows

    b5e82ba

    Define Py_GIL_DISABLED macro on Windows

    08ea7c8
  21. giampaolo
    added a commit that references this issue on Sep 30, 2024

    Define Py_GIL_DISABLED macro on Windows (#2442)

    a06e762
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

  • @zooba
    zooba

Labels

3.13only security fixesonly security fixestopic-free-threadingtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    You are visitor 01402503 — GeezerVison does not store the pages you look up.
    Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.