Free-threading removes the GIL from CPython entirely, eliminating both a process-wide lock and any per-interpreter lock. All threads in a process can execute Python bytecode in parallel within the same interpreter and against the same Python objects. This requires a special CPython build enabled at compile time with --disable-gil, commonly distributed as python3.13t so it can coexist with the normal CPython build. Free-threaded builds can still run with a GIL, depending on what the embedder requests at runtime. mod_wsgi compiled against such a Python defaults to GIL-enabled mode, and behavior changes only when WSGIFreeThreading is explicitly configured.
"Free-threading removes the GIL from CPython entirely. There is no process-wide lock to acquire and no per-interpreter lock to acquire. All threads in the process can run Python bytecode in parallel, in the same interpreter, against the same Python objects. This is fundamentally different from per-interpreter GIL, which keeps a GIL but gives each sub-interpreter its own one. Free-threading has no GIL at all."
"The feature is enabled at compile time with --disable-gil, and on platforms that distribute it the resulting binary is typically named python3.13t. The "t" suffix exists precisely so the free-threaded build can coexist on a system alongside the normal CPython build. Free-threading shipped as an experimental opt-in in Python 3.13 and continues to mature in 3.14."
"One useful detail to know is that a free-threaded build can still run with a GIL. The build supports both modes. What you get at runtime depends on what the embedder asks for. Which is the bridge into mod_wsgi's posture."
"If you compile and install mod_wsgi against a free-threaded Python, the default is still GIL-enabled. Nothing about your existing application behaviour changes until you say otherwise. The free-threaded build supports the mode; mod_wsgi dec"
Read at Grahamdumpleton
Unable to calculate read time
Collection
[
|
...
]