Repository navigation
Add a mechanism to disable the GIL #116167
Description
Activity
- addedtype-featureA feature request or enhancementA feature request or enhancement
on Feb 29, 2024 shouldn't the GIL be disabled by default in free-threading builds? (and then have
-x withgilorPYTHON_GIL=1to enable it)@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.
Reacted by Dielson Sales, Yahya Jabary and DmitryI think we want to work towards the behavior described in PEP 703 with the
Py_mod_gilslot andPTYHONGIL1 environment variable: https://peps.python.org/pep-0703/#py-mod-gil-slot.As a starting point:
- We should keep the GIL enabled by default in free-threaded builds (as it is currently is) for now.
PYTHON_GIL=0should disable the GIL
We can add the
Py_mod_gilslot and eventually disable the GIL by default later on, but hopefully still before the 3.13 release.EDIT: There seemed to be a strong preference for
UNDERSCORES_IN_NAMESin https://discuss.python.org/t/change-environment-variable-style/35180Footnotes
-
Or
PYTHON_GIL-- I think people have expressed a preference for_separated names in new environment variables ↩
Reacted by Itamar Oren, Brett Simmers, Erlend E. Aasland, Sergio Castillo and Kerim Kabirov- addedinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)
on Mar 4, 2024 - added a commit that references this issue
on Mar 11, 2024 The PEP references
PYTHONGILwhereas PR ( #116338 ) addsPYTHON_GILIs 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
The PEP references
PYTHONGILwhereas PR ( #116338 ) addsPYTHON_GILIs there a difference between these two? Or is there a plan to consolidate to with or without
_?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.
Reacted by jakirkham and Brett SimmersIIUC the python binaries distributed for Mac and Windows on python.org for 3.13 will not be built with
--disable-gil, right? And IIUC we intend for Linux distros also to have binaries namedpython3.13,python3and possiblypythonthat are built without that flag, giving the option to also distribute binaries built with--disable-gilunder different names. So this env var only applies to the latter, right? (For 3.14 the situation may be different.)The environment variable
PYTHON_GILand-X gil=0option only apply to the free-threaded binaries. Setting them with the default build cause an error on startup 1.The Windows installer can optionally also install the free-threaded executable
python3.13t.exealong with the default (with GIL) 3.13 executable. The Windows embeddable package only contains the default build (no free-threaded binaries).Example Windows installation
Directory: C:\Users\coles\AppData\Local\Programs\Python\Python313 Mode LastWriteTime Length Name ---- ------------- ------ ---- d----- 3/13/2024 2:30 PM DLLs d----- 3/13/2024 2:30 PM Doc d----- 3/13/2024 2:30 PM include d----- 3/13/2024 2:30 PM Lib d----- 3/13/2024 2:30 PM libs d----- 3/13/2024 2:30 PM Scripts d----- 3/13/2024 2:30 PM tcl -a---- 3/12/2024 10:10 PM 33861 LICENSE.txt -a---- 3/12/2024 10:12 PM 1841840 NEWS.txt -a---- 3/12/2024 10:10 PM 103192 python.exe -a---- 3/12/2024 10:11 PM 103192 python3.13t.exe -a---- 3/12/2024 10:10 PM 69912 python3.dll -a---- 3/12/2024 10:10 PM 6829336 python313.dll -a---- 3/12/2024 10:11 PM 6903064 python313t.dll -a---- 3/12/2024 10:11 PM 70936 python3t.dll -a---- 3/12/2024 10:10 PM 101656 pythonw.exe -a---- 3/12/2024 10:11 PM 101656 pythonw3.13t.exe -a---- 3/12/2024 10:10 PM 119192 vcruntime140.dll -a---- 3/12/2024 10:10 PM 49528 vcruntime140_1.dllThe 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
-
We may want to improve the error message. It's currently:
Fatal Python error: config_read_gil: PYTHON_GIL / -X gil are not supported by this build
Python runtime state: preinitialized ↩
Reacted by Brett Simmers and Кирилл-
Feature or enhancement
Proposal:
PYTHON_GIL=0 python ...orpython -Xgil=0 ...should disable the GIL at runtime, inPy_GIL_DISABLEDbuilds. 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=0or-X gil=0#116338