live wire
▸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▸SECURITY · Red Hat’s first Security Signals report shifts focus from CVE counts to risk paths (Oct. 15)Red Hat▸PLATFORM · IBM adds non-destructive FlexVolume-to-CSI migration tool for OpenShift object storageIBM Cloud▸vLLM tests agent-built Kimi K3 decode path at up to 1.9× speedup; PR remains openvLLM▸AI · LeaderWorkerSet 1.0 changes rollout defaults for disaggregated AI workloadsKubernetes SIGs▸SECURITY · Red Hat flags active exploitation of kernel flaw affecting OpenShift CoreOS; no fix listedRed Hat Product Security▸AI · Red Hat sets Dec. 9 showcase for AI 3.6 agent governance and model servicesRed Hat▸vLLM 0.32.0 drops Python 3.10, restricts CORS defaults and adds security fixesvLLM▸SECURITY · Red Hat tracks Moderate Hono auth bypass across OpenShift AI, Dev Spaces and AnsibleRed Hat Product Security▸SECURITY · Red Hat Hardened Images fixes Moderate libpng denial-of-service flawRed Hat▸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▸SECURITY · Red Hat’s first Security Signals report shifts focus from CVE counts to risk paths (Oct. 15)Red Hat▸PLATFORM · IBM adds non-destructive FlexVolume-to-CSI migration tool for OpenShift object storageIBM Cloud▸vLLM tests agent-built Kimi K3 decode path at up to 1.9× speedup; PR remains openvLLM▸AI · LeaderWorkerSet 1.0 changes rollout defaults for disaggregated AI workloadsKubernetes SIGs▸SECURITY · Red Hat flags active exploitation of kernel flaw affecting OpenShift CoreOS; no fix listedRed Hat Product Security▸AI · Red Hat sets Dec. 9 showcase for AI 3.6 agent governance and model servicesRed Hat▸vLLM 0.32.0 drops Python 3.10, restricts CORS defaults and adds security fixesvLLM▸SECURITY · Red Hat tracks Moderate Hono auth bypass across OpenShift AI, Dev Spaces and AnsibleRed Hat Product Security▸SECURITY · Red Hat Hardened Images fixes Moderate libpng denial-of-service flawRed Hat
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