5 ms·
I'm a Rust noob, and I don't understand the relationship of Tokio and the language's async/await syntax. Is there a "reference implementation" of the runtime? I
by cmckn 7y ago
I'm a Rust noob, and I don't understand the relationship of Tokio and the language's async/await syntax. Is there a "reference implementation" of the runtime? Is Tokio or another runtime required for those keywords to do anything?
I also found this blurb from the website to be confusing:
> Zero-cost abstractions
Tokio's run-time model adds no overhead compared to an equivalent system written entirely by hand.
This sounds like Tokio's impl is comparable to other impl's of "the same" system, but how does it compare to "naked Rust"?
- Ralith 7y ago"system" here is intended to refer to the application using tokio, i.e. if you got rid of tokio and did everything by hand you wouldn't be able to make your application faster.
- cmckn 7y agoAhhh; thank you!
- aliceryhl 7y agoThe standard library currently only contains what is necessary to define _what_ a Future is. It contains no tools for actually executing them, and this is the role of Tokio.
- cmckn 7y agoVery cool, so I can choose my own impl. Does Tokio have a true competitor today? From my cursory look at some projects, Tokio shows up everywhere.
- aliceryhl 7y agoThere are some other executors too such as async-std, smol and bastion, but Tokio is the one with the largest ecosystem.
- Ralith 7y agoThere's even been experiments with binding futures to glib or various GUI event loops!
- aliceryhl 7y agoI have also heard some talk on building executors for embedded devices where you can't allocate memory on the heap.
- steveklabnik 7y agoYes, this was a big constraint on the design of the overall system; there's been a couple that have popped up.
- mamcx 7y ago> and I don't understand the relationship of Tokio and the language's async/await syntax. One of the surprising things with rust here, is that it define only the syntax and some bare traits AND ALLOW TO PLUG ANY RUNTIME. This mean you can "swap" runtime implementations and even build your own. One recent example is: https://www.reddit.com/r/rust/comments/g917ad/smol_stjepang_a_small_and_fast_async_runtime_for/ https://www.reddit.com/r/rust/comments/g917ad/smol_stjepang_... This is in contrast with Go/Erlang/.NET, etc where the runtime for it is made for you, but can't be changed. This is cool where things are mostly fine all the time, but rust being a SYSTEM lang allow this is neat (example: Embebed scenarios where a regular runtime is too heavy). Note: This template show in other places, where for example you can swap the allocator or the (default) hash function.
- steveklabnik 7y agoI should also note, for balance, that this isn't perfect today. There are still some missing bits to make it truly "plug anything anywhere," but it's pretty close.
- sdegutis 7y agoThe main thing I don't understand about Rust's async/await situation is how it's not very inefficient on the CPU given that it fundamentally uses polling? https://doc.rust-lang.org/std/future/trait.Future.html https://doc.rust-lang.org/std/future/trait.Future.html
- carllerche 7y agoThe model is very similar to how epoll works. The executor does not poll futures in a loop. Between polls, the executor waits for a readiness notification. If `Future::poll` returns Pending, once it becomes ready to do more work, it notifies the executor, the executor then schedules the future to be polled again.
- mamcx 7y agoI suspect that a big part of the design of this api (and why it take time) was exactly to be as performant as possible. The compiler desugar the async/await to state machines and that is melted away by regular means. Also, the quality of the runtime elected must take some credit.