RHEL developers can now test Python without the GIL

Red Hat has made a free-threaded Python 3.14 build available for Red Hat Enterprise Linux 9.8 and 10.2. The package gives developers an officially supported upstream Python variant that can execute Python threads across multiple CPU cores without the Global Interpreter Lock, while leaving the system Python and regular Python 3.14 interpreter untouched.

This is a test-and-measure release, not a reason to rewrite every worker pool. It matters most for applications that already use threads to perform CPU-heavy work and can benefit from shared memory inside one process.

What changed

The python3.14-freethreading package is available from the CodeReady Linux Builder repositories and installs a separate python3.14t executable. Developers can therefore test the same application under the standard and free-threaded interpreters side by side.

Python 3.14 is the first upstream release where the free-threaded build is supported rather than experimental. Removing the GIL allows Python bytecode to run concurrently on several cores, addressing a longstanding limit for CPU-bound threaded programs.

The change does not make all Python software faster. Red Hat says single-threaded execution currently carries roughly 5% to 10% overhead, while applications that wait mostly on networks, databases, disks or external APIs may gain little. Existing asynchronous or multi-process designs can remain the better fit.

Who should test it

The strongest candidates are threaded data pipelines, simulations, CPU-heavy background workers and local parallel workloads that benefit from sharing Python objects. Teams should first install the package alongside their existing interpreter, run the complete test suite under python3.14t, and benchmark the actual production workload rather than a synthetic thread count.

The compatibility question is as important as speed. Pure Python code that does not share mutable state may need few changes, but programs that treated the GIL as an implicit lock can expose real races. Individual operations on built-in containers remain protected, but a sequence such as checking a dictionary key and then assigning it is not atomic; applications need explicit locks, queues or another synchronization mechanism around multi-step state changes.

C extensions are the other boundary. A third-party extension that does not support free-threading can cause Python to re-enable the GIL for the process. Overrides exist to keep it disabled, but Red Hat describes that as an at-your-own-risk choice. Dependency inventories and native-extension testing should therefore precede performance conclusions.

What to do

On RHEL 9.8 or 10.2, enable the architecture-appropriate CodeReady Linux Builder repository, install python3.14-freethreading, and invoke python3.14t. The interpreter can report whether it was built with free-threading and whether the GIL is active at runtime.

Treat the exercise as concurrency validation: identify shared mutable state, verify extension support, run race-sensitive tests, and compare throughput plus latency against the regular interpreter. The practical gain is optionality. RHEL teams can now prepare threaded applications for Python’s post-GIL path without replacing their default runtime.