Earlier quoted context omitted.
Yes, Deno uses it as its internal event loop for JS code.
Fun party fact: long ago, Rust had libuv built in too.
why’d they move past it? does libuv not fit well in rust?
Tokio 1.0 – async runtime for Rust
61–70 of 422 posts
Re: Tokio 1.0 – async runtime for Rust
#62Congrats! I've fallen off Rust due to pivoting at work plus trying other languages but I'm intrigued again by Tokio's announcement. I'll be trying out your tutorial soon!
The tokio tutorial is good, but it needs an example of spinning off multiple (2-3 or more) tasks which run forever. I ended up using spawn() multiple times and having the main thread just sleep in a loop and not using #[tokio::main] because I couldn't figure it out.
Re: Tokio 1.0 – async runtime for Rust
#63Can someone explain to a non-rustacean what Tokio introduces that's not part of Rust? It looks like Rust provides the async/await semantics, so I'm guessing this is an event loop and dispatching system?
tokio is to rust what asyncio is to Python.
except say asyncio is pet of standard python
Re: Tokio 1.0 – async runtime for Rust
#64Re: Tokio 1.0 – async runtime for Rust
#65Congrats! I've fallen off Rust due to pivoting at work plus trying other languages but I'm intrigued again by Tokio's announcement. I'll be trying out your tutorial soon!
The tokio tutorial is good, but it needs an example of spinning off multiple (2-3 or more) tasks which run forever. I ended up using spawn() multiple times and having the main thread just sleep in a loop and not using #[tokio::main] because I couldn't figure it out.
You can await std::future::pending, or you can just await the Join Handles returned by the calls to spawn.
Re: Tokio 1.0 – async runtime for Rust
#66Earlier quoted context omitted.
Fun party fact: long ago, Rust had libuv built in too.
why’d they move past it? does libuv not fit well in rust?
Rust used to have a lot of stuff built into the language, including garbage collection![0] I think that a long time ago they chose to move stuff out into libraries so that Rust could be a serious competitor to C++.
https://pcwalton.github.io/2013/06/02/removing-garbage-colle...
Re: Tokio 1.0 – async runtime for Rust
#67Can someone explain to a non-rustacean what Tokio introduces that's not part of Rust? It looks like Rust provides the async/await semantics, so I'm guessing this is an event loop and dispatching system?
AFAIK, the major component is the scheduler.
Rust can't really implement green threading (imagine Golang) by default, because it requires the runtime to be bundled in the executable, and the code to be compiled in a specific way to be managed by the scheduler.
I actually find amusing the thought that _this_ is systems programming. In a low level language one can implement the functionality of a higher level language (ie. Golang), but not the reverse :-)
Re: Tokio 1.0 – async runtime for Rust
#68They mention working on using io_uring for filesystem calls for 2021. I wonder if there will be an option to use io_uring (instead of epoll) for networking calls as well? Handling network packets and events completely in userspace should allow for lower latency due to no more context switches to and from the Kernel, right?
Both epoll and io_uring depend on the kernel to do the "actual IO", if you want really user-space you need DPDK and a userspace network stack (for TCP/UDP).
Both epoll and io_uring have virtually the same performance. Of course uring is a lot more "ergonomic" that's why it already has amazing momentum.
Re: Tokio 1.0 – async runtime for Rust
#69Can someone explain to a non-rustacean what Tokio introduces that's not part of Rust? It looks like Rust provides the async/await semantics, so I'm guessing this is an event loop and dispatching system?
In very loose terms: Rust's async/await syntax defines an interface to async programming, not an implementation.
Rust leaves the implementation, and thereby choice of concurrency strategy, to libraries. Tokio is such a library. There's at least one other popular one of note.
Re: Tokio 1.0 – async runtime for Rust
#70They mention working on using io_uring for filesystem calls for 2021. I wonder if there will be an option to use io_uring (instead of epoll) for networking calls as well? Handling network packets and events completely in userspace should allow for lower latency due to no more context switches to and from the Kernel, right?
There's some interesting bits on the low-level work for using io_uring with the Ringbahn crate - https://boats.gitlab.io/blog/post/ringbahn/
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!