Introducing Vibeio

We’re excited to announce vibeio - a new high-performance, cross-platform, thread-per-core asynchronous runtime for Rust.

This asynchronous runtime is designed specifically for a thread-per-core architectures. In thread-per-core architectures, one thread is dedicated to each CPU core, to decrease context switching and improve cache locality. This architecture is used in systems that need low latency, high throughput, and predictable performance.

Why vibeio?

Currently, we’re using Monoio (or rather its fork) as a primary asynchronous runtime for the Ferron web server. It’s a high-performance thread-per-core asynchronous runtime for Rust that can utilize io_uring completion-based I/O.

However, we have seen from the commit history that Monoio upstream seems to be not-so-well maintained.

That’s why we created vibeio - we’re planning to replace Monoio with another asynchronous runtime.

We tried porting Ferron to Compio (another thread-per-core runtime that supports io_uring and IOCP), however the web server performance was lower overall (with HTTP/2) than even if Ferron ran with Tokio.

But why not Tokio?

From the vibeio README:

Tokio is a popular asynchronous runtime for Rust, but it uses a work-stealing model and may introduce additional synchronization overhead when using it as a thread-per-core runtime. vibeio is more specialized for thread-per-core architectures that are optimized for low overhead and cache locality.

But is it vibe-coded!?

Ah, we get it… 😅

We have named this asynchronous runtime “vibeio”, from “vibe” (from “vibe coding”, because this runtime was coded with help of AI) and a common suffix for Rust asynchronous runtimes, “-io”.

However, we have debugged some parts ourselves, like io_uring use-after-frees that led to memory corruption, some zombie process reaper-related test hangups on macOS or fixing UDP test failures on Windows (since ConnectEx function works on connection-bound sockets only; also, handles couldn’t be registered multiple times in I/O completion ports).

Features

From the vibeio README:

vibeio provides an efficient I/O event loop that leverages the best available driver for each operating system:

• Linux - uses io_uring for true asynchronous I/O.
• Windows - uses I/O Completion Ports (IOCP) for scalable I/O.
• macOS / BSD / Others - uses kqueue or epoll via mio for event notification.

• Networking - asynchronous TCP, UDP, and Unix Domain Sockets.
• File system - asynchronous file operations.
• Timers - efficient timer and sleep functionality.
• Signals - handling of OS signals.
• Process management - spawning and managing child processes.
• Blocking tasks - offload CPU-intensive or blocking operations to a thread pool.

Getting started

You can check out the GitHub repository for vibeio at https://github.com/ferronweb/vibeio!

If you would like to get started with vibeio, add it to your Cargo.toml for a Rust project:

[dependencies]
vibeio = "0.1"

Here’s an example of using vibeio (TCP echo server):

use vibeio::RuntimeBuilder;
use vibeio::net::TcpListener;

fn main() -> std::io::Result<()> {
    // 1. Build the runtime
    let runtime = RuntimeBuilder::new()
        .enable_timer(true)
        .build()?;

    // 2. Run the main future
    runtime.block_on(async {
        let listener = TcpListener::bind("127.0.0.1:8080")?;
        println!("Listening on 127.0.0.1:8080");

        loop {
            let (mut stream, _) = listener.accept().await?;

            vibeio::spawn(async move {
                let (mut reader, mut writer) = vibeio::io::split(stream);
                if let Err(e) = vibeio::io::copy(&mut reader, &mut writer).await {
                    eprintln!("Echo failed: {}", e);
                }
            });
        }
    })
}

In practice, you would start multiple threads per each CPU core and pin them (for example using core_affinity crate.

To learn more about how to use vibeio, visit its crate documentation.

If you would also like to build an HTTP server using Hyper and vibeio, you can use the vibeio-hyper crate.