-
-
Notifications
You must be signed in to change notification settings - Fork 30.6k
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
Add a mechanism to disable the GIL #116167
Comments
shouldn't the GIL be disabled by default in free-threading builds? (and then have |
@colesbury probably has more thoughts, but I believe we're expecting disabling the GIL to be pretty buggy initially. So even if we're targeting disabling the GIL by default in 3.13, we'll probably want the GIL to stay on by default for a while first. |
I think we want to work towards the behavior described in PEP 703 with the As a starting point:
We can add the EDIT: There seemed to be a strong preference for Footnotes
|
…116338) In free-threaded builds, running with `PYTHON_GIL=0` will now disable the GIL. Follow-up issues track work to re-enable the GIL when loading an incompatible extension, and to disable the GIL by default. In order to support re-enabling the GIL at runtime, all GIL-related data structures are initialized as usual, and disabling the GIL simply sets a flag that causes `take_gil()` and `drop_gil()` to return early.
The PEP references Is there a difference between these two? Or is there a plan to consolidate to with or without Sorry I know this is a minor question, but want to help avoid potential confusion down the road |
there's no difference - underscored env vars is the current preference among core devs (discussion & poll) the implementation & documentation are the source of truth, and may differ from the PEP in some ways. |
IIUC the python binaries distributed for Mac and Windows on python.org for 3.13 will not be built with |
The environment variable The Windows installer can optionally also install the free-threaded executable Example Windows installation
The macOS installer does not currently support installing the free-threaded build. I'm not sure what the plan is for 3.13. Your summary of the Linux situation matches my understanding. Footnotes
|
…il=0` (python#116338) In free-threaded builds, running with `PYTHON_GIL=0` will now disable the GIL. Follow-up issues track work to re-enable the GIL when loading an incompatible extension, and to disable the GIL by default. In order to support re-enabling the GIL at runtime, all GIL-related data structures are initialized as usual, and disabling the GIL simply sets a flag that causes `take_gil()` and `drop_gil()` to return early.
…il=0` (python#116338) In free-threaded builds, running with `PYTHON_GIL=0` will now disable the GIL. Follow-up issues track work to re-enable the GIL when loading an incompatible extension, and to disable the GIL by default. In order to support re-enabling the GIL at runtime, all GIL-related data structures are initialized as usual, and disabling the GIL simply sets a flag that causes `take_gil()` and `drop_gil()` to return early.
Feature or enhancement
Proposal:
PYTHON_GIL=0 python ...
orpython -Xgil=0 ...
should disable the GIL at runtime, inPy_GIL_DISABLED
builds. This will be similar in spirit to colesbury/nogil-3.12@f546dbf16a.Has this already been discussed elsewhere?
I have already discussed this feature proposal on Discourse
Links to previous discussion of this feature:
https://peps.python.org/pep-0703/
Linked PRs
PYTHON_GIL=0
or-X gil=0
#116338The text was updated successfully, but these errors were encountered: