-
-
Notifications
You must be signed in to change notification settings - Fork 30.7k
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.
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
gh-111650: Ensure pyconfig.h includes Py_GIL_DISABLED on Windows #112778
Conversation
zooba
commented
Dec 5, 2023
•
edited by bedevere-app
bot
Loading
edited by bedevere-app
bot
- Issue: Py_GIL_DISABLED not defined in "free-threaded" Windows C-API extensions #111650
@@ -739,4 +739,7 @@ Py_NO_ENABLE_SHARED to find out. Also support MS_NO_COREDLL for b/w compat */ | |||
/* Define if libssl has X509_VERIFY_PARAM_set1_host and related function */ | |||
#define HAVE_X509_VERIFY_PARAM_SET1_HOST 1 | |||
|
|||
/* Define if you want to disable the GIL */ | |||
#undef Py_GIL_DISABLED |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you want to rename the PC/pyconfig.h
? It seems like some tools might treat the input template as if it's the true pyconfig.h
file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not actually a template, it's a totally valid and usable header file. In the default case (for now), Py_GIL_DISABLED
is undefined, and we just change that on build if requested.
For editing in an IDE, we need some kind of actual header file available or else all the code assistance tools will fail. Rather than requiring the IDE understand the build directory (which VS can do, but others may not), this allows us to have a default GIL_DISABLED
header before building and then the correct one when actually building.
The failure in the nogil build is an access violation/segfault (see the end of the build step where we get the real exit code - 0xC0000005), and it doesn't repro on my own machine. I've merged from master again in case it was unlucky and a re-run helps, but otherwise this could be a tricky one to diagnose. |
@zooba, I'll see if I can reproduce it locally |
The files in |
Ah, that makes sense. Easily fixed |
Actually, I can't see how that happens unless your build differs from mine. (Side note - we should enable verbose output in CI so that we could see exactly what was happening there... the default output isn't detailed enough.) What is happening is that the extension modules that are outside the core DLL are getting the unmodified header, because they have independent I'll add a new project just to do the header file update, so that way the dependencies/incremental build can work properly and we don't have to repeat the process for every module. |
That's happening too for me (later on in the build), but files like |
There shouldn't be a case where |
And yet, I'll hack things together a different way. |
I fixed the test, and found that the crash is because I don't see any obvious reason for the failure, and |
@zooba - I haven't seen the With that change I'm able to build |
However,
|
Yeah, apparently it works today? I see the last push I did also didn't crash. Hopefully it's not uninitialised memory, as that would be annoying to track down. |
!buildbot windows |
🤖 New build scheduled with the buildbot fleet by @colesbury for commit 6c067b7 🤖 The command will test the builders whose names match following regular expression: The builders matched are:
|
It looks like cpython/Tools/peg_generator/pegen/build.py Lines 140 to 145 in 1c5fc02
|
Output directory is the one to add ( I do intend to send a PR to setuptools for this, I just haven't yet, and I'd be more inclined to skip the test until that's in. Or if we've actually vendored setuptools, we can just patch our copy for now.1 I'm pretty sure setuptools trusts us enough to merge the change before we merge ours, but I wouldn't blame them if they didn't - it's not their circular dependency. Footnotes
|
My guess is that this is due to #86179 which I should probably just fix (pretty sure it only needs a |
!buildbot windows |
🤖 New build scheduled with the buildbot fleet by @zooba for commit c74133b 🤖 The command will test the builders whose names match following regular expression: The builders matched are:
|
@colesbury Anything else you think should be handled in this PR? Once this is in (and my other one to fix symlinks and simplify the new sysconfig code) I've got a broader range of build changes to make, so we likely won't have to live with this particular code for long. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great!
@@ -16,7 +16,7 @@ jobs: | |||
steps: | |||
- uses: actions/checkout@v4 | |||
- name: Build CPython | |||
run: .\PCbuild\build.bat -e -d -p Win32 ${{ inputs.free-threaded && '--disable-gil' || '' }} | |||
run: .\PCbuild\build.bat -e -d -v -p Win32 ${{ inputs.free-threaded && '--disable-gil' || '' }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you want to keep this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it slows down CI enough to be a problem.