smol VS rio

My understanding is you always need a runtime, somethings needs to drive the async flow. But there are others on the market, just not without the.. market domination... of tokio.

https://github.com/smol-rs/smol looks promising simply for being minimal

https://github.com/bytedance/monoio looks potentially easier to work with than tokio

https://github.com/DataDog/glommio is built around linux io_uring and seems somewhat promising for performance reasons.

I haven't played with any of these yet, because Tokio is unfortunately the path of least resistance. And a bit viral in how it's infected tings.

There is also https://github.com/smol-rs/smol which has components which you can compose into your own executor if you still need async IO but your usage patterns don't fit into the general purpose ones that Tokio provides.

If you need precise control over scheduling, consider building something on top of https://github.com/smol-rs/smol

Tokio is a "take what you need" framework, whilst Async-std started as an "everything the box" solution. Today both have a lot of crossover with micro async runtimes like smol becoming the foundation one of framework and optionally usable in the other. The ability to rip out a small dependent sub-crate (dependent package) like smol and use it independently with ease never get's boring, by the way. It's great way to include a test runtime in an async library without forcing the inclusion of a giant async framework.

Helix uses tokio. smol might be a good alternative however.

No, still active on GitHub. What gave you that idea? https://github.com/smol-rs/smol

Found the issue in Google cache. I'm not sure it's really fair of me to post this link here, but equally I think it's better to give the actual text rather than leave it vague.

https://webcache.googleusercontent.com/search?q=cache:PRjMyv...

Also, not to be too bad about a reputation fallacy, but I found the author to be flippant and disrespectful when good-faith unsoundness was pointed out in his crates: https://github.com/spacejam/rio/issues/30

In my previous post on linear types I spent quite a bit of time motivating linear types. For example the ergonomic rio io_uring library could be made sound if it could guarantee destructors are run. Or performing FFI with async C++ could be made more efficient if it could rely directly on destructors rather than having to involve an intermediate runtime for each call.

It's like cargo should have a way to mark a dependency as unsafe. That way, you could have a safe mmap crate as an unsafe dependency. Or something like rio which is deliberately unsound (but is fine if you abide by its rules through the entirety of the program)

for completeness there is also rio, but:

rio still has known soundness issues– its Completion futures block the thread when dropped (!!!), and can allow for use-after-free bugs if leaked. See https://github.com/spacejam/rio/issues/30 for details.

Here are some posts about the design. https://without.boats/blog/io-uring/ https://github.com/spacejam/rio/issues/30 https://github.com/axboe/liburing/issues/109

The author of sled[1], an embedded database in Rust which has a number of promising features, has also written parts of rio[2], an underlying pure Rust io_uring library, which is intended to become the core write path for sled. rio has support for files but also has a demo for TCP (on Linux 5.5 and later) and O_DIRECT.

I tested rio recently as I had a Brilliant but Bad Idea™ involving file access and was pleasantly surprised by the API, as I have been with sled's.

I'm excited for the experimentation in the Rust ecosystem and for such low level crates to handle the complex io_uring tasks (relatively) safely!

[1]: https://github.com/spacejam/sled

[2]: https://github.com/spacejam/rio