You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PYTHON_GIL=0 python ... or python -Xgil=0 ... should disable the GIL at runtime, in Py_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
@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.
IIUC 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 named python3.13, python3 and possibly python that are built without that flag, giving the option to also distribute binaries built with--disable-gil under different names. So this env var only applies to the latter, right? (For 3.14 the situation may be different.)
The environment variable PYTHON_GIL and -X gil=0 option 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.exe along with the default (with GIL) 3.13 executable. The Windows embeddable package only contains the default build (no free-threaded binaries).
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
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 ↩
Activity
itamaro commentedon Feb 29, 2024
shouldn't the GIL be disabled by default in free-threading builds? (and then have
-x withgilorPYTHON_GIL=1to enable it)swtaarrs commentedon Feb 29, 2024
@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.
colesbury commentedon Feb 29, 2024
I 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:
PYTHON_GIL=0should disable the GILWe 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 ↩gh-116167: Allow disabling the GIL with `PYTHON_GIL=0` or `-X gil=0` (#…
jakirkham commentedon Mar 12, 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
itamaro commentedon Mar 12, 2024
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.
gvanrossum commentedon Mar 13, 2024
IIUC 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.)colesbury commentedon Mar 13, 2024
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
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
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 ↩
swtaarrs commentedon Mar 13, 2024
Once gh-116749 is complete, we can start running tests in CI with the GIL disabled using one of these flags (or by doing gh-116329).
This is finished unless someone wants to keep it open to track improving the error message (from Sam's last comment).
pythongh-116167: Allow disabling the GIL with `PYTHON_GIL=0` or `-X g…
pythongh-116167: Allow disabling the GIL with `PYTHON_GIL=0` or `-X g…