gh-116167: Allow disabling the GIL with PYTHON_GIL=0 or -X gil=0
#116338
Conversation
|
!buildbot nogil |
|
🤖 New build scheduled with the buildbot fleet by @swtaarrs for commit ac24233 🤖 The command will test the builders whose names match following regular expression: The builders matched are:
|
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. With `PYTHON_GIL=0` set, I spot-checked a few tests and small programs that don't use threads. They all seem to run fine, and very basic threaded programs work, sometimes. Trying to run the full test suite crashes pretty quickly, in `test_asyncio`.
swtaarrs
force-pushed
the
cpython-disable-gil
branch
from
ac24233
to
9e03999
Compare
|
!buildbot nogil |
|
🤖 New build scheduled with the buildbot fleet by @swtaarrs for commit 9e03999 🤖 The command will test the builders whose names match following regular expression: The builders matched are:
|
There was a problem hiding this comment.
Good to add test case in this file too.
cpython/Lib/test/test_cmd_line.py
Line 896 in 72714c0
|
You can just add the testcase for the environment variable, still worth to adding it. |
|
At not for this PR, since this feature is not officially announced, but in some moment, you should write about the environment variable at https://github.com/python/cpython/blob/72714c0266ce6d39c7c7fb63f617573b8f5a3cb2/Doc/using/cmdline.rst to get user feedback. |
|
!buildbot nogil |
|
🤖 New build scheduled with the buildbot fleet by @swtaarrs for commit 4f43a87 🤖 The command will test the builders whose names match following regular expression: The builders matched are:
|
What would be a good time to do that? Maybe once the GIL is disabled by default, so the description doesn't have to change? |
|
I would document the environment variable now, when it's added. For reference, we already document the I don't think it needs to be extensive, but should cover:
The behavior when then environment variable is not set is what's going to change in the future. We can document that later. |
|
After discussion in Discord, I'm also going to add a |
swtaarrs
changed the title
PYTHON_GIL=0PYTHON_GIL=0 or -X gil=0
|
This is both exciting and very scary. Congrats @swtaarrs and @colesbury :-) |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
In free-threaded builds, running with
PYTHON_GIL=0or-X gil=0will now disable the GIL. #116322 and #116329 track follow-up work to re-enable the GIL when loading an incompatible extension, and to disable the GIL by default, respectively.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 at startup that causes
take_gil()anddrop_gil()to return early.With
PYTHON_GIL=0set, I spot-checked a few tests and small programs that don't use threads. They all seem to run fine, and very basic threaded programs work, sometimes. Trying to run the full test suite crashes pretty quickly, intest_asyncio.