It does seem like it. This is, to my knowledge, the first hugely popular I/O library which now lets its users use io_uring in a way which just looks like normal async file I/O.
Rust seems like it is in a special position in that it’s a language with good enough performance for io_uring to matter, but with powerful enough facilities to make clean abstractions on top of io_uring possible.
Isn’t the problem that Rust bet the farm on readiness-based APIs and now it turns out (surprise) that completion-based APIs are generally “better” and finally coming to Linux (after Windows completely embarrassed Linux on that matter for like a decade).
It’s not a problem in practice. Rust’s futures model handels io-uring just fine. There was some debate over how to handle “cancellations” of futures, e.g. when Rust code wants to just forget that it asked the OS for bytes from a TCP socket. But the “ringbahn” research prototype found a clean solution to that problem.
Actually, that entire blog is a wealth of information about Rust futures.
I’d call that a stretch, considering that the “solution” pretty much foregoes futures altogether (and with that async/await) and largely rolls its own independent types and infrastructure.
So I’m not seeing how this is evidence for:
futures model handels io-uring just fine
I’d say its evidence of the opposite.
Actually, that entire blog is a wealth of information about Rust futures.
Actually, that blog is the reason why I asked the question in the first place.
I’m getting a little out of my depth here, but my understanding is that ringbahn (which inspired the tokio implementation) is meant to be used under the hood by a futures executor, just like epoll/kqueue are used under the hood now. It’s a very thin interface layer.
Basically, from application code you start up a TCP socket using an async library with io-uring support. Then whenever you read from it and await, the executor will do ringbahn-style buffer management and interface with io-uring.
Isnt this… Really big?
It does seem like it. This is, to my knowledge, the first hugely popular I/O library which now lets its users use io_uring in a way which just looks like normal async file I/O.
Rust seems like it is in a special position in that it’s a language with good enough performance for io_uring to matter, but with powerful enough facilities to make clean abstractions on top of io_uring possible.
Isn’t the problem that Rust bet the farm on readiness-based APIs and now it turns out (surprise) that completion-based APIs are generally “better” and finally coming to Linux (after Windows completely embarrassed Linux on that matter for like a decade).
It’s not a problem in practice. Rust’s futures model handels io-uring just fine. There was some debate over how to handle “cancellations” of futures, e.g. when Rust code wants to just forget that it asked the OS for bytes from a TCP socket. But the “ringbahn” research prototype found a clean solution to that problem.
Actually, that entire blog is a wealth of information about Rust futures.
I’d call that a stretch, considering that the “solution” pretty much foregoes futures altogether (and with that
async/await) and largely rolls its own independent types and infrastructure.So I’m not seeing how this is evidence for:
I’d say its evidence of the opposite.
Actually, that blog is the reason why I asked the question in the first place.
I’m getting a little out of my depth here, but my understanding is that ringbahn (which inspired the tokio implementation) is meant to be used under the hood by a futures executor, just like epoll/kqueue are used under the hood now. It’s a very thin interface layer.
Basically, from application code you start up a TCP socket using an async library with io-uring support. Then whenever you read from it and await, the executor will do ringbahn-style buffer management and interface with io-uring.
There’s also hugely popular https://github.com/libuv/libuv/pull/2322
(Since libuv isn’t modular it hasn’t officially landed yet, but the way I understand it, both projects are at about the same level of completion)
Everything about rust is big now =)
Rust is the epitome of Big FOSS.
This is huge! I’m gonna play with this after work. Excited to see where this ends up!