Decrusting the tokio crate

In this stream, we peeled back the crust on the tokio crate - github.com/tokio-rs/tokio/ - and explored its interface, structure, and mechanisms. We talked about blocking, cancellation, spawning, and mechanisms for synchronization. We also dug into some of what goes on under the hood where that ends up being relevant to you as an application author!
For more details about tokio, see docs.rs/tokio/.
Discord: discord.jonhoo.eu
0:00:00 Introduction
0:02:28 The parts of tokio
0:05:19 The tokio runtime
0:29:08 Blocking
0:48:09 Send bounds and LocalSet
0:51:04 tokio vs std Mutex
0:56:53 Runtime questions
1:06:00 tokio resources
1:28:19 tokio::fs nuances
1:33:47 tokio::process nuances
1:36:27 tokio::io things
1:47:30 tokio-stream
1:56:13 tokio::sync
2:11:10 tokio::task::JoinSet
2:19:13 tokio::select! and cancellation
2:51:26 tokio-util and CancellationToken
3:03:35 common errors: tokio::spawn
3:07:25 common errors: concurrency vs parallelism
3:08:53 common errors: mpsc fan-in
3:12:08 Follow-up questions and outro
Live version with chat: kzbin.infoYlTyZvpaywQ

[@brendanwenzel]

Dude, the level of depth you go into is so far beyond anyone else in this space. Seriously, you're an animal!

[@0x1337feed]

a Rustanean to be accurate

[@volkan8583]

GOAT must be applicable here

[@christsciple]

I have been writing code since I was a wee little eleven year old boy, now going on almost 30 years and time and again I am humbled and learn new something new with each video of yours! These are truly gems Jon!

[@felixcantournet]

the tokio::pain!() (instead of pin) typo is just *chef_kiss*

[@oof-software]

The "Async in depth" entry in the tokio tutorials is also a really nice read! I didn't really understand the whole waker thing before reading that.

[@ahuggingsam]

Love these streams! Could I also request a de crusting stream on the nom crate? That would be very helpful to me. Thanks for all you do either way!

[@sbx1720]

My dude delivered quality content again! Thank you sir. Please continue with the series.

[@burgerking4for410]

Just today I was thinking "Hmm, is there a 'Decrusting Tokio'?". Great!

[@christopher8641]

As always, thank you so very much for putting the time into these videos. I've written tons of code with tokio and still managed to absorb some new thoughts and concepts. Maybe an idea for a future crust of rust might be an implementation of an async executor. Although, I'm not sure if it is a large endeavor, or a bit too deep in the weeds. I love that these videos are not step by step tutorials but rather a tutorial on how someone could arrive at an implementation. It's patterns instead of recipes.

[@sagnikc395]

thanks for this stream, just finished the riust book a few days back and wanted to learn about async programming in rust in depth . this is invaluable !!!

[@loobersoog]

Another invaluable stream

[@Fyyro]

Hey, excited to watch the video! You mentioned your discord server and said the link outloud but a link in the description you could click would be super nice!

[@jonhoo]

Done!

[@HangyuanLiu-mw5ud]

I just started reading the chapter about asynchronous programming from your rust book. And this is the perfect companion to the reading.

[@austinbelknap125]

A helpful follow-on to this video would be the "tonic" crate, particularly how streaming RPCs work with tokio stream.

[@bobby9568]

Amazing Jon is at it again!

[@flyingsquirrel3271]

That watch channel seems useful. In fact, after watching your video about channels, I implemented a sync version of exactly that idea (never published). It makes sense to just look into these modules to get to know the tools available. I guess I should do that more often :)

[@rasoulmesghali]

So excited to watch this brilliant video, thanks Jon

[@cappuccinopapi3038]

Does anyone know if there's something similar to this channel for Golang? The quality of learning material for Rust is just extraordinary

[@pratikkulkarni891]

Have you checked out Ultimate Go by William Kennedy? It's not a channel rather a course, but goes in pretty deep in the language.

[@user-hn1cy5ee5l]

If I am not mistaken regarding select and why you can not pass future.await in select "arms" is that .await is simply instruction to await for the future and it should actually prevent from progressing the function body further. So that's why you need to pass a future and select will handle all of the "polling" tasks on it's own

[@12e2aela7]

Hi Jon, Thank you for your invaluable stream 🦀

[@leonie9248]

Yes!!! Thank you so much!

[@rustprogrammer]

What an excellent video!

[@navibongo9354]

Godly video man!

[@user-hj3oh3to9j]

will you talk about pin trait in another crust of rust video? I think it's hard for me to understand = =

[@ridcully]

Very helpful talk

[@LB767]

Not sure I understood the difference between awaiting a bunch of futures in a LocalSet and just using a regular join! macro?

[@NeronRVV]

Could you explain or link to something that goes into detail on why Sink trait is not that great? My only guess is that encoding data is usually less error prone than decoding it, so additional trait on top of AsyncWrite might be redundant. Edit: should've waited for a few minutes before commenting

[@rajmajumdar5253]

Wow this is insane bro, really insane, nobody has gone to this much depth. Many thanks . Also can you tell me how you have the top bar of the firefox below? Also which fork of Firefox are you using?

[@jonhoo]

Thanks! For setup-related things, see kzbin.info/www/bejne/rp7Uoa2mr8mdf5o :)

[@drvanon]

About notify-ing and moving to the runnable queue. If i were to only implement Future, how would the runtime figure out when to try polling?

[@antonf.9278]

The poll method takes a context that contains a waker. This waker seems to come from the runtime and you are supposed to wake it to indicate that you are ready to be polled again. To call the waker you need to gain control of the CPU, this comes from the kernel (or the hardware directly if you run bare metal) and depends on the specific thing you are doing. If you call the kernel it should take a callback and without a kernel you need set a hardware interrupt.

[@luckystrike91]

why rust doesn't have push-based stream (rx)?

[@bruceritchie7613]

Til cargo expand .. among a bunch of other things! Thx!

[@vimau010]

Thanks!

[@Lucs-ku5cb]

Next "decrusting Iced crate"

[@junhaozhu4763]

How come you know so many details? I cannot find such resource elsewhere.

[@christopher8641]

Experience, fork the code base, ask questions, make small but quality contributions, write a ton of code, read a ton of code

[@tiagoneves7068]

Que aula 🎉

[@kylidboy]

best of the best

[@yokebabjr3866]

Why do we need AsyncRead/AsyncWrite in the first place? Couldn't they juste be a special case of Stream/Sink where the element is an u8?

[@jonhoo]

They technically could, but that would be very very inefficient. There's generally overhead to every method call, even if it's usually fairly small, and incurring that for every single byte read or written would be too much for a lot of workloads.

[@ACIB708]

holy shit!

[@dominicfischer2891]

"I'm not gonna get too deep into How to write an asynchronous scheduler" 😿

[@deanroddey2881]

It all sounded good until the whole mutex discussion. Obviously objects having mutexes always run the risk of helper methods recursively locking and other issues. But the number of gotchas required by async for these and other issues sort of undermines a major benefit of Rust which is it doesn't require every team member to be a veteran, human vigilance to avoid housekeeping issues, and minimizes spooky action at a distance. Those issues seem to undermine the potential simplification of using async a good bit in practical terms. I could see doing my own bespoke baby 'runtimes' for very specific scenarios, where the async'ness doesn't infect everything I guess, and where the complexity remains fairly low because it's not trying to be all things to all people.

[@jonhoo]

Clippy actually already has a lint for catching using the wrong kind of mutex (rust-lang.github.io/rust-clippy/master/index.html#/await_holding_lock), and there's been an effort to get it into rustc itself (github.com/rust-lang/rust/issues/71072). You can also always _safely_ use the async version of the mutex, it's only if you try to use the sync version (to boost performance) that you have to be careful. Note further that using the sync version inside of sync code that is then called by async code is _also_ not a problem since sync code doesn't contain any awaits (by definition).

[@noviriustomeisho6630]

Can you turn this into a playlist instead of video annotations? It's very difficult to rewind when a sliver of the play bar is basically 10min

[@jonhoo]

You should be able to go directly to each chapter either by clicking the timestamps in the video description, or by clicking the name of the chapter and then KZbin will give you a full chapter list on the right just like how a playlist is shown :)

[@deryilz]

on desktop, you can also do ctrl with the right or left arrows to move to the start of chapters