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!
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.
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 !!!
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!
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
3:08:52 Regarding inefficiency of processing data one by one with `mpsc` instead of doing it in batches (in a form of e.g. `Mutex`) I believe methods `mpsc::Receiver::recv_many` and `poll_recv_many` have been created to solve exactly this problem.
Looks like that's only on tokio channels, not std ones? Even so, those are helpful, but they only help with the acquisition cost - they don't let you do things like work compaction (eg, if a later update replaces an older one rather than add to it).
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 :)
At 45:14 - 48:00 you talk about shutdown, and unless I misunderstood the documentation you make incorrect statements. for instance: when the main future exits, the OS does NOT immediately shut down all the threads - from the docs: 'Tasks spawned through Runtime::spawn keep running until they yield. Then they are dropped. They are not guaranteed to run to completion, but might do so if they do not yield until completion. Blocking functions spawned through Runtime::spawn_blocking keep running until they return. The thread initiating the shutdown blocks until all spawned work has been stopped. This can take an indefinite amount of time. The Drop implementation waits forever for this.' also, shutdown_background & shutdown_timeout do NOT shutdown gracefully.
1:04:39 I don't know if it's been addressed later on, but there's definitely a difference between Tokio Instant and std Instant. In if the testing feature is enabled, Tokio Instant works off an internal clock so Tokio can time warp through sleep calls so tests don't take forever.
Also tokio mpsc channel use semaphore with capacity as permits number. Same for mpsc queue custom implementations is useful (like with cordyceps crate)
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
At #2:00:34, what does it mean "whoever reads it first has it" talking about Receiver of mpsc? there is just one receiver, there is no second or third receiver.
The CancellationToken is just like C# one, except that methods with are async always have a CancellationToken as the last parameter instead of being inside a select arm.
The fact that this video has 60k is the problem with Rust. People come to Rust, from languages which have concurrency primitives like coroutines (and no multi threading) and therefore think that it's a good idea to reach for async first (instead of pure multi threading). My from-the-hip guess, is that I suspect 90% of all projects using Tokio shouldn't and are probably *worse off* for doing so. Coroutines are very rarely better than pure multi threading in my experience and opinion. For many reasons, really.
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.
39:00 what if you spawn more OS threads ( std::thread::spawn) from within spawn_blocking? Would that block all other Tokio workers or would Tokio handle that?
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.
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.
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).
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?
Okay what is going on in Japan and why are so many Tokyo workers running around grabbing futures. I just woke up and I'm half asleep and TH-cam autoplay this and I do not understand anything that is being said. Who is waking up Japanese poll workers and why?
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 TH-cam will give you a full chapter list on the right just like how a playlist is shown :)
Thanks for those videos. You should really mute yourself when you drink, cough, swallow etc.. cause it’s really loud and disturbing… keep up the good work !
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!
Dude, the level of depth you go into is so far beyond anyone else in this space. Seriously, you're an animal!
a Rustanean to be accurate
GOAT must be applicable here
This dude is an animal. Seriously
yeah the animal, the GOAT
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.
My dude delivered quality content again! Thank you sir. Please continue with the series.
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.
the tokio::pain!() (instead of pin) typo is just *chef_kiss*
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 !!!
Another invaluable stream
Would love an episode dedicated to tokio channels and async synchronization of a multi threaded tokio program.
Just today I was thinking "Hmm, is there a 'Decrusting Tokio'?". Great!
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!
Done!
Jon is a rust beast , incredibly skilled you rock
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
3:08:52 Regarding inefficiency of processing data one by one with `mpsc` instead of doing it in batches (in a form of e.g. `Mutex`) I believe methods `mpsc::Receiver::recv_many` and `poll_recv_many` have been created to solve exactly this problem.
Looks like that's only on tokio channels, not std ones? Even so, those are helpful, but they only help with the acquisition cost - they don't let you do things like work compaction (eg, if a later update replaces an older one rather than add to it).
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 :)
Amazing Jon is at it again!
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!
nom isn’t well maintained these days - consider switching to winnow.
Does anyone know if there's something similar to this channel for Golang? The quality of learning material for Rust is just extraordinary
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.
At 45:14 - 48:00 you talk about shutdown, and unless I misunderstood the documentation you make incorrect statements.
for instance:
when the main future exits, the OS does NOT immediately shut down all the threads -
from the docs:
'Tasks spawned through Runtime::spawn keep running until they yield. Then they are dropped. They are not guaranteed to run to completion, but might do so if they do not yield until completion.
Blocking functions spawned through Runtime::spawn_blocking keep running until they return.
The thread initiating the shutdown blocks until all spawned work has been stopped. This can take an indefinite amount of time. The Drop implementation waits forever for this.'
also, shutdown_background & shutdown_timeout do NOT shutdown gracefully.
A helpful follow-on to this video would be the "tonic" crate, particularly how streaming RPCs work with tokio stream.
1:04:39 I don't know if it's been addressed later on, but there's definitely a difference between Tokio Instant and std Instant. In if the testing feature is enabled, Tokio Instant works off an internal clock so Tokio can time warp through sleep calls so tests don't take forever.
So excited to watch this brilliant video, thanks Jon
Hi Jon, Thank you for your invaluable stream 🦀
Next "decrusting Iced crate"
will you talk about pin trait in another crust of rust video? I think it's hard for me to understand = =
Can't show my thanks any more. You are a great presenter!
I watched 3 hours of this late at night after it appeared from autoplay, idk what you were saying but it was good background noise 8/10
Also tokio mpsc channel use semaphore with capacity as permits number. Same for mpsc queue custom implementations is useful (like with cordyceps crate)
Til cargo expand .. among a bunch of other things! Thx!
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
Not sure I understood the difference between awaiting a bunch of futures in a LocalSet and just using a regular join! macro?
At #2:00:34, what does it mean "whoever reads it first has it" talking about Receiver of mpsc? there is just one receiver, there is no second or third receiver.
The CancellationToken is just like C# one, except that methods with are async always have a CancellationToken as the last parameter instead of being inside a select arm.
Earned a new subscriber ❤
The fact that this video has 60k is the problem with Rust. People come to Rust, from languages which have concurrency primitives like coroutines (and no multi threading) and therefore think that it's a good idea to reach for async first (instead of pure multi threading). My from-the-hip guess, is that I suspect 90% of all projects using Tokio shouldn't and are probably *worse off* for doing so.
Coroutines are very rarely better than pure multi threading in my experience and opinion. For many reasons, really.
coroutines are often better than pure multithreading as a lot of people deal with io bound workloads
What an excellent video!
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?
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.
39:00 what if you spawn more OS threads ( std::thread::spawn) from within spawn_blocking? Would that block all other Tokio workers or would Tokio handle that?
Then it would be the OS scheduler that would choose to give CPU time to either the tokio worker threads or the OS threads you spanwed
How come you know so many details? I cannot find such resource elsewhere.
Experience, fork the code base, ask questions, make small but quality contributions, write a ton of code, read a ton of code
Thank you, Jon 🙏
why rust doesn't have push-based stream (rx)?
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?
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.
Godly video man!
Very helpful talk
Yes!!! Thank you so much!
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.
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).
Thanks!
best of the best
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?
Thanks! For setup-related things, see th-cam.com/video/xmqpzpzdjI8/w-d-xo.html :)
This is one crusty corner of rust.
Que aula 🎉
Okay what is going on in Japan and why are so many Tokyo workers running around grabbing futures. I just woke up and I'm half asleep and TH-cam autoplay this and I do not understand anything that is being said. Who is waking up Japanese poll workers and why?
holy shit!
"I'm not gonna get too deep into How to write an asynchronous scheduler" 😿
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
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 TH-cam will give you a full chapter list on the right just like how a playlist is shown :)
on desktop, you can also do ctrl with the right or left arrows to move to the start of chapters
Thanks for those videos. You should really mute yourself when you drink, cough, swallow etc.. cause it’s really loud and disturbing… keep up the good work !
Thanks!