mio

Mio is the foundation beneath many async runtimes in Rust, and using it directly feels like working with syscalls wrapped in a thin Rust layer. The documentation is technically accurate but assumes you already understand epoll/kqueue concepts. I spent hours debugging edge-triggered vs level-triggered modes before finding buried examples that clarified the differences. The API itself is clean—registering sockets with Poll and iterating events is straightforward once you grasp the model.

Error messages are mostly helpful, though "spurious wakeups" and "would block" errors require understanding OS-level I/O semantics. Common pitfalls like forgetting to re-register interests after edge-triggered events aren't well-surfaced. GitHub issues get responses, but many questions are redirected to "use Tokio instead." The examples directory is decent for basic cases, but real-world patterns like handling partial writes or connection state machines require piecing together multiple examples.

For building custom async runtimes or understanding how Tokio works internally, mio is invaluable. For typical application development, the cognitive overhead rarely justifies bypassing higher-level frameworks.

Mio is the bedrock underneath most async Rust runtimes (tokio, async-std), and using it directly gives you tight control over non-blocking I/O with minimal abstraction. From a security perspective, this is refreshingly lean - there's no TLS handling, no authentication layer, no parsing logic that could introduce vulnerabilities. You're working directly with OS-level primitives (epoll, kqueue, IOCP) through a safe Rust interface.

The API is explicit about error handling - you deal with io::Result everywhere and there's no magic hiding failures. Token-based interest registration makes it hard to accidentally leak data between connections. However, this low level means you're responsible for everything: implementing timeouts, handling partial reads/writes securely, ensuring buffers don't expose uninitialized memory. The documentation assumes you understand event-driven I/O patterns.

Dependency-wise, mio has minimal transitive deps (libc, log) which reduces supply chain risk considerably. The maintainers respond to issues promptly and CVE history is clean. Updates are conservative and don't break APIs unnecessarily.

Mio is the battle-tested building block underneath tokio and other async runtimes. Using it directly gives you fine-grained control over epoll/kqueue/IOCP operations without the higher-level runtime overhead. The API is minimal and predictable - you register interest in events, poll for readiness, then perform non-blocking operations. Error handling is explicit and doesn't leak system internals inappropriately.

From a security perspective, mio excels at secure-by-default design. File descriptors are properly managed with CLOEXEC flags set automatically. The library doesn't make TLS/crypto decisions for you (that's intentional - it's I/O only), but it provides the right hooks for layering security on top. Input validation is your responsibility at the application layer, which is correct for this abstraction level. No hidden global state or magic that could introduce TOCTOU issues.

The CVE response history is excellent - the maintainers are responsive and transparent. Dependencies are minimal (libc, log, and platform-specific syscall wrappers), reducing supply chain risk significantly. Documentation clearly explains platform differences and edge cases around partial reads/writes.