monoio-rs/monoio

Rust async runtime based on io-uring.

View on GitHub ↗Jump to charts ↓

Data as of . Signed-in members get hourly updates — create a free account.

Summary Information

Updated 2 hours ago
Added to GitGenius on September 13th, 2026
Created on November 30th, 2021
Open Issues & Pull Requests: 89 (+0)
GitHub issues: Enabled
Number of forks: 296
Total Stargazers: 5,125 (+0)
Total Subscribers: 51 (+0)

Repository Insights (GitGenius)

Median issue/PR response: 2.3 days
Mean response time: 112.9 days
90th percentile: 321.8 days
Tracked items: 41

How this project is maintained

97% of open issues come from outside the core team, so the backlog reflects real-world use rather than internal planning. Three people close 64% of everything that gets resolved.

Charts & Analytics

Fetching additional details & charts...

Issue Activity (beta)

Open issues: 33
New in 7 days: 0
Closed in 7 days: 0
Avg open age: 587 days
Stale 30+ days: 33
Stale 90+ days: 31

Recent activity

Opened in 7 days: 0
Closed in 7 days: 0
Comments in 7 days: 0
Events in 7 days: 0

Top labels

  • F-feature-request (26)
  • documentation (1)
  • good first issue (1)

Most active issues this week

Sign in to see which issues are moving.
Sign in

Detailed Description

Monoio is a thread-per-core Rust async runtime based on io-uring, epoll, and kqueue.

The runtime addresses the need for high-performance I/O handling in server applications by implementing a thread-per-core execution model rather than work-stealing. Unlike Tokio-uring, which runs on top of another runtime, Monoio operates as a standalone runtime that directly uses native asynchronous I/O APIs. This design eliminates the requirement for tasks to be Send or Sync, allowing safe use of thread-local storage since data does not escape threads at await points. The approach targets I/O-bound server workloads such as load balancers, where operations concentrate on network sockets and thread-local data does not need to be shared between cores.

Monoio suits projects built as load balancers or other network-intensive servers where the workload distributes evenly across cores and I/O dominates computation. The runtime requires Rust 1.75 or later and, for io-uring support, a Linux kernel version 5.6 or newer with properly configured memlock settings. On older Linux versions, the runtime falls back to epoll mode. macOS systems can use kqueue. The tool is not suitable for workloads with highly unbalanced task distribution, as underutilized CPU cores may degrade performance compared to work-stealing runtimes. Windows support is experimental.

Development activity shows consistent engagement with the codebase through regular updates and refinements to the runtime's core functionality. The project maintains associated libraries for thread-local channels, TLS support, and codec utilities, indicating active expansion of the ecosystem around the core runtime. Documentation covers platform-specific requirements and configuration details, reflecting attention to deployment concerns. The maintainers acknowledge design trade-offs explicitly, such as the incompatibilities introduced by the custom I/O abstraction and the performance characteristics under unbalanced workloads.