live wire
▸Red Hat ships important MicroShift 4.16.73 security updateRed Hat Product Errata▸AI · Red Hat maps local AI Inference serving and load tests on RHEL (Oct. 15)Red Hat Emerging Technologies▸PLATFORM · IBM guide maps Secure Execution VMs onto OpenShift Virtualization for LinuxONEIBM Community▸AI · vLLM maps Nemotron 3.5 Super VL across Hopper, Blackwell and Red Hat DSpark (Oct. 15)vLLM Recipes▸AI · AWS contributes push-based KV transfer to vLLM, reporting 3x better TTFT under loadAWS Machine Learning Blog▸AI · AWS contributes bidirectional KV transfer to vLLM, cutting multi-turn TTFT up to 3.3xAWS Machine Learning Blog▸AI · vLLM Semantic Router adds d3-turbo with box and video-tracking decisionsvLLM Semantic Router▸IDENTITY · Keycloak DevDay 2027 opens call for deep technical talks through Oct. 24Keycloak▸AI · vLLM Recipes maps Muse Spark Open to single-node Blackwell and AMD deployment (Oct. 16)vLLM▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security▸Red Hat ships important MicroShift 4.16.73 security updateRed Hat Product Errata▸AI · Red Hat maps local AI Inference serving and load tests on RHEL (Oct. 15)Red Hat Emerging Technologies▸PLATFORM · IBM guide maps Secure Execution VMs onto OpenShift Virtualization for LinuxONEIBM Community▸AI · vLLM maps Nemotron 3.5 Super VL across Hopper, Blackwell and Red Hat DSpark (Oct. 15)vLLM Recipes▸AI · AWS contributes push-based KV transfer to vLLM, reporting 3x better TTFT under loadAWS Machine Learning Blog▸AI · AWS contributes bidirectional KV transfer to vLLM, cutting multi-turn TTFT up to 3.3xAWS Machine Learning Blog▸AI · vLLM Semantic Router adds d3-turbo with box and video-tracking decisionsvLLM Semantic Router▸IDENTITY · Keycloak DevDay 2027 opens call for deep technical talks through Oct. 24Keycloak▸AI · vLLM Recipes maps Muse Spark Open to single-node Blackwell and AMD deployment (Oct. 16)vLLM▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security
upstreambeat.ai
releasePLATFORM

RHEL developers can now test Python without the GIL

RHEL 9.8 and 10.2 package Python 3.14’s supported free-threaded build alongside the standard interpreter, giving CPU-bound threaded applications a migration path—and a new race-condition test.

Standard and free-threaded Python 3.14 side by side on RHEL.
Side by side: what changed
By The News Desk· Sep 14, 2026the quick take — two AI hosts go live when you do

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.

sources

Filed by The News Desk. Corrections: desk@upstreambeat.ai · Our standards →

comments · 0

    Comments are moderated before they appear. Your email is used once to confirm it is you — never shown, never sold. Corrections and questions get an answer from the desk when we have one.

    more from the desk