Glommio: a thread-per-core Rust runtime built on io_uring

The problem Glommio solves, and who it is actually for

Most Rust async runtimes are work-stealing schedulers. A future can start on one worker thread and finish on another, which is convenient for throughput but means every shared structure between tasks needs synchronisation, and cache lines move between cores as tasks migrate. Glommio takes the opposite position. It is a cooperative thread-per-core crate, and the README states plainly that unlike its counterparts it does not use helper threads anywhere. Each executor is local to a thread, tasks on that executor stay on that thread, and sharing happens because you chose to share, not because the scheduler moved your work.

The audience is narrow and specific. You need Linux, you need a kernel with io_uring, and you need a workload where the cost of cross-core synchronisation is the thing you are trying to remove. A sharded key-value store, a network proxy, a storage engine: these are the shapes that fit. A CLI tool that reads a config file and exits is not. The README's own framing is that Glommio makes writing highly parallel asynchronous applications in a thread-per-core architecture easier for rustaceans, which is a statement about a design philosophy as much as a library.

What Glommio is not is a drop-in replacement for the runtime you already use. The API shape forces you to think about which thread owns which future, and that thinking is the point.

How the io_uring mechanism shapes the API

Glommio is built on io_uring, the Linux asynchronous I/O interface. The README's supported-kernel section sets the floor at 5.8, described as recent enough to run discovery probes. That is a real constraint, not a formality: on an older kernel the crate cannot start.

The runtime model follows from that. A LocalExecutorBuilder spawns an executor bound to the calling thread, and the future you hand it runs there. Because there is no work-stealing, a task that awaits does not get picked up by a different core. That removes a class of data races by construction, and it also means you cannot accidentally get parallelism inside one executor. Parallelism comes from spawning multiple executors, one per core, and sharding your work across them. The examples directory reflects this: sharding.rs exists as a separate example from hello_world.rs, and the repository ships examples covering cooperative preemption, deadlines, gates, and storage, each of which maps to a scheduling concern you have to handle yourself rather than delegate to a runtime.

The cooperative part matters too. A future that never yields blocks its executor, and since there is no helper thread to fall back on, nothing else on that core runs. The cooperative_preempt.rs example exists precisely because preemption is a discipline the application author maintains, not something the scheduler imposes.

Installing Glommio and running a first executor

Glommio is published on crates.io, and the README points to the docs page and an introductory article for more detail. The repository is a Cargo workspace whose members are examples and glommio, so the crate is consumed as a normal dependency rather than built from a vendored tree.

Before any code runs, the kernel and the resource limit have to be right. The README gives the memlock adjustment directly, editing /etc/security/limits.conf so that the hard and soft limits are raised, then logging in again so the change takes effect.

$ vi /etc/security/limits.conf
*    hard    memlock        512
*    soft    memlock        512

After logging back in, the README says to confirm with ulimit -l, which should print 512. The README also warns that 512 KiB is the minimum for a single executor and that spawning multiple executors may require raising the limit further. This is the step people skip, and it is the step that produces a failure at spawn time rather than at compile time.

$ ulimit -l
512

With the limit in place, the first real program is the README's own example: build a LocalExecutorBuilder, spawn an async block, and join it.

use glommio::prelude::*;

LocalExecutorBuilder::default().spawn(|| async move {
    // your async code here
})
.expect("failed to spawn local executor")
.join();

If that runs to completion, the executor spawned, the future executed on the calling thread, and the join returned. From there, the examples directory is the better next step than the docs: echo.rs for networking, storage.rs for io_uring file I/O, and sharding.rs for the multi-executor pattern. The README states the minimum supported Rust version is 1.70 and that the crate is built against the latest stable release, so check your toolchain before the first build.

Where Glommio is the wrong tool

The Linux and io_uring requirement is the first hard boundary. A crate that needs kernel 5.8 cannot ship in a binary that targets macOS, Windows, or an older Linux distribution, and no amount of feature-flagging in your own code changes that. If your product is a cross-platform CLI, stop here.

The locked-memory requirement is the second. Every executor needs at least 512 KiB of memlock, and the README notes that more executors may need more. On a container runtime with a tight memlock limit, or a shared host where you cannot edit limits.conf, this is an operational problem before it is a code problem.

The third boundary is subtler. Thread-per-core removes cross-core synchronisation costs, but it does not create parallelism within a core. A CPU-bound task that would benefit from spreading across all cores gets nothing from Glommio's model; you would spawn one executor per core and shard manually, which is work a work-stealing runtime does for you. And because the model is cooperative, a future that holds a lock or does a long synchronous computation stalls its executor with no fallback. The crate does not rescue you from that, and the README does not claim it does.

Glommio compared with Tokio and Monoio

Tokio is the default answer for Rust async, and the difference is architectural rather than cosmetic. Tokio provides a multi-threaded work-stealing scheduler by default, so a task can migrate between worker threads, and it offers a current-thread runtime when you want to opt out. Glommio has no work-stealing mode to opt out of: thread-per-core is the only model, and the README's claim that it uses no helper threads anywhere is the whole distinction. If your code is written against Tokio's multi-threaded runtime and relies on tasks being freely scheduled, porting to Glommio is a redesign of how state is shared, not a dependency swap.

Monoio is the closer comparison, and the searches around Glommio vs Monoio reflect that. Both are thread-per-core runtimes built on io_uring, which means they share the same kernel floor and the same no-helper-thread premise. The difference to evaluate is in the surrounding API surface and the ecosystem each one integrates with, not in the scheduling philosophy, which is largely the same. That makes the choice between them a question of which crate's I/O abstractions and example set match your workload, rather than which runtime model you prefer.

Against both, Glommio's distinguishing feature is that it is maintained under the DataDog organisation and documents a specific kernel and resource-limit contract up front. That contract is the thing to read before anything else.

Maintenance, versions, and what the licence actually says

The most recent release listed is v0.7.0 from 2022-02-10. The release before it, v0.6.0, is labelled First production grade release, and v0.5.1 is described as fixing two regressions. The repository itself is not archived, and the last push was on 2026-08-31, so there is ongoing commit activity even though the published crate version has not moved in some time. That gap between repository activity and crates.io releases is worth noting if your build depends on a specific published version: you may be reading documentation for behaviour that only exists on master.

On licensing, the README states the crate is licensed under either the Apache License, Version 2.0 or the MIT license, at your option. The repository carries LICENSE-APACHE and LICENSE-MIT files, and also a LICENSE-3rdparty.sh script and a NOTICE file, which is the pattern you see in projects that vendor or depend on third-party code with its own terms. The metadata for the repository reports the licence as NOASSERTION, which is a machine-readable classification and not a statement about the actual terms; the README and the two licence files are the sources to read. Dual Apache-2.0 and MIT is a permissive combination, but the NOTICE and third-party script mean the dependency tree is worth checking if your organisation has a policy on attribution. That is a question for your own legal review, not something the README settles.

Upgrade cost is dominated by the kernel floor rather than the API. Moving to a newer Glommio means confirming the target deployment still meets the io_uring and memlock requirements, and re-checking any code that assumed a particular executor behaviour.

Editorial conclusion

Adopt Glommio when your service is Linux-only, your workload is I/O bound against io_uring, and you want each core to own its own executor without a work-stealing scheduler moving tasks between threads. Do not adopt it for cross-platform binaries, for CPU-bound parallel computation, or for a codebase where the team has not internalised the difference between a LocalExecutor and a multi-threaded runtime. Before committing, verify three things on your own hardware: that the kernel is at least 5.8, that ulimit -l reports at least 512 KiB per executor you intend to spawn, and that your futures do not hold a borrow across an await point. The crate is a single-purpose runtime, and the cost of getting those three wrong shows up as a failed spawn or a compile error, not a silent slowdown.

Frequently asked questions

Official sources

1. DataDog/glommio on GitHub
2. Issues
3. README
4. Releases