« All posts

Runloom Brings Go-Style Stackful Coroutines to Python

Runloom is a Go-style coroutine library for free-threaded Python 3.14t, spawning millions of fibers per core. It beats Go on spawn speed but trails on memory use.

Runloom is a stackful coroutine library that brings a Go-like goroutine model to free-threaded CPython 3.13t/3.14t (GIL off). Instead of async/await, it lets developers write code that looks blocking via fiber(fn), while monkey.patch() cooperatively rewires existing stdlib calls (socket, time, threading) without code changes. Under the hood it uses a hand-written assembly context switch, a per-hub work-stealing scheduler, and epoll/kqueue/IOCP-based netpoll, plus Go-style channels and select.

The project's own benchmarks are notable: on a 64-core box, Runloom's pure-C spawn rate beats Go's (2.29M/s vs 2.10M/s), though Python-level spawning lags at roughly 0.65x of Go's throughput. Context-switch cost and connection/request throughput land near parity with Go — a keep-alive test with a Python handler hits 596K req/s versus Go's 603K. The clearest gap is memory: an idle parked fiber carries a full CPython eval frame, giving it roughly 3.3x the RSS of an empty Go goroutine.

The authors are upfront that the multi-core advantage depends entirely on free-threaded CPython builds; on GIL-enabled Python, Runloom still works but behaves single-core, similar to asyncio. Preemption only happens at bytecode boundaries, so tight C calls (e.g., numpy) can still hold a hub hostage — the same limitation Go has with cgo. Linux x86_64 on 3.13t is the primary, most heavily validated target, with other platforms (macOS, Windows, aarch64) less deeply tested. For engineers, Runloom offers a blocking-style alternative to async/await for I/O-heavy, multi-core Python workloads once the GIL is out of the picture.