I often feel I don't have enough time to watch a 30 minute video but spending 2+ hours watching your content is something I will make time for. Fantastic contribution to grokking Rust ... thank you.
This was great! Even though you described it before, I didn't _get_ the "await/yield returns back to the thing that awaited" part until you answered the "do futures stay on a thread" question and then it clicked. And the async trait fn part was great because it always seems more intuitive when you describe why things that I expect should work, don't work. It also tied off why the stack variables part was important so nicely.
I finally understand the formal difference between concurrency and parallelism because of the 01:19:00 Your content is amazing. Thank you for putting it out!
This was an amazing watch! The state machine unveil was an "aha" lightbulb moment for me, since I knew some of the background of how async executors work, but didn't really know how the macros worked and how the desugaring happened. Also, now that async traits are a thing, and RPIT in traits work, it would be great to have a follow up video discussing the new way and what are the gotchas there. Thank you so much for putting out amazing educational material like this for free! I only started learning rust like a week ago and I feel like I understand stuff so much more than I would expect to because of deep videos like this!
i love you. it helped me SO MUCH! i'm gonna send this video to all my rust friends who struggled with this. awesome channel, i like that livestream idea.
For me the easiest way to understand async was writing it in C. Of course that not everyone knows C syntax, but it really gives you a complete understanding of how simple async is and how you can leverage blocking syscalls
Pretty new to Rust and don't really have any async/await requirements or anything, but I've always wondered how it worked under the hood. This was the perfect video for learning, thanks so much 😄
Thanks for the effort you put into these videos and trying to help people understand difficult stuff. Great teaching, great presentation, great video :)
At 1:25:20, one of the `&mut connections` is in the "futures" section and one in the "matched handler block", where all other "futures" have already been dropped, so there wouldn't be any problem with the compiler.
2:12:23 why does it have to be Arc if it's executing in a single thread? Also why does it have to be a mutex if since it's a single thread then no concurrent access will be happening?
Yes that's how it works. Each .await encapsulates a state. async fn foo() { //State1 begins.. let x = bar().await; //State1 ends .. //State2 begins.. let y = x.prop1.setColor("whatever"); let z = y.paint_screen().await; //State2 ends.. // State3 begins .. return z.status_code; //State3 ends.. //End state begins (shouldn't be poll()ed after this). }
thanks a lot for this stream / vod. its amazing to see into detail, what a feature actually does. i hope we can see some more in the future (pun intended :-))
Any variable that needs to be shared across states needs to be passed into the new state while transitioning. Example, // Inside poll() definition match *self { Self::State1(x) => { // Do stuff *self = Self::State2(x, some_new_state); // That's it for State1's job. }, Self::State2(x, y) => { // ... *self = Self::End; }, Self::End => { panic!("poll () shouldn't be called after future is completed"); }, _ => unreachable!(), } // End of match statement. Each time poll () is called, you do work and potentially shift into a different state.
Would it make sense to have something like off-CPU analysis with bpf for futures on tokio executor? Some async-aware instrumentation might be able to hook into yield points and probe stack traces also saving timestamps.
Yup, I think there's been some talk about that already. Possibly by having a tracing subscriber that introduces labels that you can then refer to from bpf too. It's a tooling ecosystem that's very much still in its infancy though!
At 57:00, it's mentioned that if there's a future that's blocking on something that takes forever, (and therefore never yields), nothing ever gets the chance to run. But stuff can still run on another thread right? (Assuming the chosen tokio runtime is multithreaded?
Yep, I talk about that a little later in the video. The devil is in the details here though. For example, Tokio implements (at least, implemented) an optimization that makes it faster to schedule a future that recently ran, which in turn makes that future not possible to steal. So if you block an executor thread, you _also_ block that additional future. Which may in turn prevent other futures from running that depend on that future running. Basically, blocking the executor can have grave and unexpected consequences, so don't do it 😅
@@jonhoo noted. So what I'm gathering so far is that it's fairly easy to reap the full benefits of async/await as long as you adhere to a few simple rules
@32:52 "every await is an opportunity to chose to do something else". I assume this is only true if the awaited future is not immediately ready (im thinking of `std::future::ready()`) ?! I.e. futures are eagerly progressed, if possible. Only if there are some special os or async-framework specific calls controll will be yielded and other futures may progress. Is that correct?
No, futures are *not* eagerly professed. The executor is allowed to to run the same future again, but is under no obligation to do so. And generally it'll take the opportunity to run another future instead.
Is there a reason Tokio itself reimplements the std::fs functions directly for example? Rather than having an executor-agnostic async standard library crate?
Because in general the I/O resource types (like TcpStream) need to communicate with the executor in order for the executor to know what events to wait for when it decides to put a thread to sleep. And there is no executor-agnostic way to do that currently. We may eventually get something like that, but likely not any time soon.
If my async function does an IO in a very deep call stack, does it have a lot of overhead everytime the future is polled? Because the poll need to check the state of the top of the call stack, down to the last call stack that actually perform the IO.
2:13:00 I feel there needs to be a way to get a warning when calling a blocking function in an async function. It would solve exactly these kinds of problems. I will have to look into it.
It's funny, coming from JavaScript, conceptualizing futures and async await feels natural. It's threads that confuse me yet it looks like most people in the comment section are in the opposite camp
Greate explanation, In Asynchronous mutexes you said that using standard library mutex for short operation is safe but I think it's true for single thread async app, But if we have more than 1 thread always there is a chance that two parts of code refer to same mutex that may lead to deadlock, certainly in short operation this chance is very low but it's still possible.
I know it's a big topic, but I want to dive deeper in how unix based systems actually handle async events and parallel operations. At the very least I want to understand what the basic level async facilities are (network calls, file operations, what else could be async??). Do you have recommendations for materials on this topic?
This is very useful even though I don't use rust, only c++. This will definitely help for when I make my own multithreaded async yield system using c++20 co routine features. (With c++20 modules features, too. Let's see how many compiler bugs I will hit!)
Any reasonable threaded scenario would use a thread pool for handling clients, so it wouldn't be an issue and would (IMO) still be easier to understand. To me the async model feels weird, and hides what is going on more, which I don't consider really a good thing when there are multiple things going on. And it lets you be sure you have a thread per client (if you want that), whereas that's not the case in the async model, where I assume you are depending on some internal heuristics as to how many threads are being created and when. The thread pool based system has a much more controllable response time to connections. A generic interface for waiting on things (and for things to make themselves waitable) of course is simple and obvious, and can be used in many ways, without the obfuscation of the async system. And for those things that you really are likely want to want to wait on already probably have OS level (and wrappable by the runtime) mechanisms to have them be done asynchronously and signaled, so you can easily make those waitable without any of the overhead of the async system. As a cooperative multi-tasking, it's really not useful for latency sensitive operations, except when everything it does is truly async and very light weight, and if you have to carefully ensure such things, what have you really gained in terms of simplicity? And how easy would it be for code changes to introduce something not light weight without it being at all obvious from reading the code?
If you have a thread pool / green threads, you already are in the woods of cooperative multitasking. All the technical drawbacks of async/await apply, and the choice is simply about taste/style. If you want true OS threads it proves to be too much of an overhead (for example Apache) to be competitive against an async/await high performance server (e.g. Nginx) And yes, it is true that async await and coroutines in general is only good if your application is really low on compute, and dead heavy on IO, but that is really what a web server is, for like 99% of the time
@@cat-.- And there are now many web servers in the world, meaning real ones that need huge I/O throughput, not simple ones in devices and such? They would be about 0.0001% or some such of applications. And could still achieve the same thing even lighter weight than green threads by directly using async I/O.
If a executor have 2 future spawned and are in epoll ready, one's f.poll() return Ready and done. How will the executor return the ready value to the .await. and will/if it continue after .await on that future?. or will it wait for 2nd future.
Fantastic talk - the only thing I would say is missing is more detail on how to deal with dynamically sized selects (i.e. the number of futures varies over time). Are Futures(Un)Ordered involved or tokio streams?
In the functional programming world we put our "effectful" operations in an "effect" type (Like cats IO in Scala)... so is it fair to say that in the Rust world, corresponding idea is to use futures and async/await?
Ah, no, this isn't a way to describe whether an operation does I/O or not. Synchronous code can also do I/O. It is solely a matter of using a different execution model.
This is probably a very stupid question, but in foo2() why do you want to “sleep” until a future is resolved? I mean why not just block? What’s the benefit of going to “sleep” and being woken up by the OS if you’re in a non UI environment like a CLI? Is it because you’d save on computational cycles that would normally be wasted? Again, sorry if it’s a stupid question. I understand the use case with select!, but not in a “regular” code.
I didn't get a YT notification for this :(. I would have liked to ask whether it was normal for tokio select! to poll without being explicitly notified by a waker? I have a delay_queue the impls Future and it gets several extra calls to poll by select! before select! actually sleeps and waits for the waker. It feels kinda like debouncing. I would expect it the poll function to be called twice. Once on init and then finally when the waker notifies the executor and the future completes...
Well, sort of. Futures aren't themselves green threads, since they don't actually run on their own, but when combined with an executor you effectively get green threading.
I'm curious what you feel like that would add in this video? I usually do run my code, but here most of what I've written is more about the types, and running it wouldn't actually print anything 😅 For much of it, there'd also be a bunch of not particularly interesting extra code to write to get things to compile, which would make the video probably twice as long without actual contributing any further insights or understanding.
Hello, I saw your video on TH-cam above and thought it was very good. I am from China and would like to translate your video into Chinese subtitles for Chinese video sites, what authorization do I need?
Hi there! You don't need any authorization. The videos are licensed under Creative Commons specifically for this purpose. Please provide a link back to the video and/or to my Twitter though :)
With the select! macro, lets say I have 2 things that I'm waiting on. The first is a TCP socket that gets data from the network in a highly variable manner. Sometimes I get packets from it between 1 second to 1 hour. (This also means that I have to keep the connection alive by sending it a ping to the server every 30 seconds.) The second is a UDP socket that gets data from the network in a much more consistent manner. I get a packet from there between 50 milliseconds to 6 seconds. Both of these packets are getting parsed out and saved to different SQLite databases on the backend. The TCP one is doing a lot of computation on that packet and indeed could make another TCP connection to another server, or send a HTTP request to another service this takes a lot of time. Is there a guarantee within the runtime that the if I get another TCP packet or UDP packet before that computation is done that it will also handle the next TCP packet as well? Or am I going to spill the next packet on the floor as it flows past what my program is able to handle. What about the UDP side that is waiting for TCP to handle its packet. Given that the TCP side could take several seconds to finish its processing of that packet, would I be dropping UDP packets on the floor because my TCP future is running and hogging the system?
Partially answered at 55:35 - You would need to call .await on these expensive functions call in the TCP socket to make sure that it yields back to the select call. What it does't answer is if another TCP packet comes in, would that TCP packet get processed as well, or would the new TCP packet clobber the handling of the previous packet that is still in flight, or would it drop that packet, or would it queue the packet for the next iteration into the select macro call. -- The solution (but not the answer) for that comes at 1:27:00 where they talk about giving that packet (or connection in their example) to the executor for them to handle and make progress on until it's done.
I considered rust for writing a highly asynchronous I/O heavy application, however I ran into trouble when I was trying to await on a few lists of futures of different types. Additionally, at the end of a task from a list sometimes I would add some more to one of the other lists, meaning that I had to really select on these lists and depending on which task was finished, possibly modify these lists. I am new to Rust so I don't know if I was missing something but I found no way to do just that (selecting on multiple lists of different types of futures), do you know if / how it could be done?
The way I'd do this is to tokio::spawn each future, and then add all the returned join handle futures to a FuturesUnordered which you can then pull from.
@@jonhoo Thanks, I used std async just because I thought it's the standard having std in the name :)). But I see tokio is really the most used and fully featured one, I'll try again with tokio and see what results I get.
I feel really weird that the futures don't really execute until .await is called on them, while there is a background worker thread that could've taken that future and polled it to completion. Are there any executors that immediately start polling the future (in a background thread) as soon as they are made? (Eg: the future in its construction pushes itself to a worker_queue that the executor pops the futures out of and distributes them to worker threads).
This model of not executing a future immediately only works if you have a lot of futures to poll/execute so that the background thread isn't really wasting time when the future wasn't .await-ed .
No, there is no such executor. And there couldn't be - there's nothing special about the creation of a future that an executor could hook into. In fact, even await doesn't actually make a future run. It just says that *when* this future runs, and gets to this point, it must wait for this other future. It's only when a future is given to an executor that it actually runs.
@@jonhooWell yes, you are right in that Rust doesn't have some notion of "default constructor" that gets run, which would've made this elegant. However at the expense of more boilerplate, couldn't we write an extension method on Futures, say .run(), that spawns the future in a new Task/parallel compute, and returns some sort of handle that you can call .await on? Would it be possible to do this without too much synchronisation problems?
Never seen the "select" macro, the JS way would be to add .then() on each promise and then do Promise.all(). That way, you can still react to each individual promise resolving but you also have guarantee that the process will not continue until all promises have resolved. Not sure how that would work in Rust. Event if you added a .then() function on a future, I guess there might be some complications with the borrow checker. I will have to try it out to find out.
With C++ futures, its interesting to note that there is different behavior: #include #include auto f() -> std::future { return std::async(std::launch::async, [] { std::cout
Depends on the executor. I believe Tokio will generally catch panics to prevent the executor threads from terminating, and then propagate that to join handles, but the documentation should say.
I often feel I don't have enough time to watch a 30 minute video but spending 2+ hours watching your content is something I will make time for. Fantastic contribution to grokking Rust ... thank you.
Thanks!
This was great! Even though you described it before, I didn't _get_ the "await/yield returns back to the thing that awaited" part until you answered the "do futures stay on a thread" question and then it clicked. And the async trait fn part was great because it always seems more intuitive when you describe why things that I expect should work, don't work. It also tied off why the stack variables part was important so nicely.
I finally understand the formal difference between concurrency and parallelism because of the 01:19:00
Your content is amazing. Thank you for putting it out!
Wow, this introduction is spectacular. Thanks for the beautiful content.
This channel is the only one of its kind. Please don't ever stop! :)
I'm not even a Rust engineer, and i've still sat through most of the video. This is the kind of content I love watching.
This was an amazing watch! The state machine unveil was an "aha" lightbulb moment for me, since I knew some of the background of how async executors work, but didn't really know how the macros worked and how the desugaring happened.
Also, now that async traits are a thing, and RPIT in traits work, it would be great to have a follow up video discussing the new way and what are the gotchas there.
Thank you so much for putting out amazing educational material like this for free! I only started learning rust like a week ago and I feel like I understand stuff so much more than I would expect to because of deep videos like this!
You may find th-cam.com/video/CWiz_RtA1Hw/w-d-xo.htmlsi=GcR0lZnT3tKds9UO interesting too :)
@@jonhoo wow, thank you so much!
Man, was really hard wrapping my head around this, until I found this video.
Thanks for sharing.
You are super good at explaining things! Been learning a lot watching this series. Thanks!
thanks... it's great when we can see through the magic and the world makes sense again! I watch these things for start to finish...
this is the best lecture about async Rust. Thank you
Thank you so much. I feel I finally getting into rust and start understanding why compiler complains on my code and how to fix it.
i love you. it helped me SO MUCH! i'm gonna send this video to all my rust friends who struggled with this. awesome channel, i like that livestream idea.
More of this is needed on TH-cam. Thank you for comparing to other languages like JavaScript promises, that helped me personally.
Hey I’ve always enjoyed your streams but somehow never knew you were writing a book. I’m glad you mentioned it so I was able to preorder a copy!
For me the easiest way to understand async was writing it in C.
Of course that not everyone knows C syntax, but it really gives you a complete understanding of how simple async is and how you can leverage blocking syscalls
are there any resources out there about this? I kinda want a guide to implement this, thanks in advance!
Useful? It was HUGELY valuable, especially given that it's one giant recorded live stream - simply amazing. Cheers!
excelent explanations on the hows and whys of async. Thank you! 👏🏻👏🏻
Valeu!
Pretty new to Rust and don't really have any async/await requirements or anything, but I've always wondered how it worked under the hood. This was the perfect video for learning, thanks so much 😄
Thanks for the effort you put into these videos and trying to help people understand difficult stuff. Great teaching, great presentation, great video :)
Thank you, Jon, I love videos that convey the essence professionally.
At 1:25:20, one of the `&mut connections` is in the "futures" section and one in the "matched handler block", where all other "futures" have already been dropped, so there wouldn't be any problem with the compiler.
I don't know any rust but I still watch these videos, idk why.. you're good
Great content and delivery as always! Enjoying the new book too, interesting and challenging!
Manually writing async FSMs in C really gives you appreciation for the niceties of this syntax sugar
This... is such a great introduction. Thanks for sharing with us.
That was very useful. Coming from scala I now have a better understanding and know what the differences are.
Just noticed it's your birthday today.. (what are the odds😅) Happy Birthday Jon! Thanks a lot for your high-quality videos! Super helpful!
excellent content as usual jon 👏
2:12:23 why does it have to be Arc if it's executing in a single thread? Also why does it have to be a mutex if since it's a single thread then no concurrent access will be happening?
The spawn() call requires it since it is allowed to handle it in a new thread, not only the current one. (It's not necessarily single threaded.)
I am grateful to find this video. Thanks for awesome explanation :)
Thank you, I'm very excited to watch this. :)
A good way of picturing it is the number of awaits in your future equal to the number of states in the state machine it's being turned into. 15:00
Yes that's how it works. Each .await encapsulates a state.
async fn foo() {
//State1 begins..
let x = bar().await;
//State1 ends ..
//State2 begins..
let y = x.prop1.setColor("whatever");
let z = y.paint_screen().await;
//State2 ends..
// State3 begins ..
return z.status_code;
//State3 ends..
//End state begins (shouldn't be poll()ed after this).
}
thanks a lot for this stream / vod. its amazing to see into detail, what a feature actually does. i hope we can see some more in the future (pun intended :-))
0:25 "[This] is gonna be one of the shorter streams..." 2.5hrs long? Surprisingly correct.
Thank you soooo much for this. I Finally understand how this stuff works.
In the "Stack variables in async" example, how does chunk2 access x?
Any variable that needs to be shared across states needs to be passed into the new state while transitioning.
Example,
// Inside poll() definition
match *self {
Self::State1(x) => {
// Do stuff
*self = Self::State2(x, some_new_state);
// That's it for State1's job.
},
Self::State2(x, y) => {
// ...
*self = Self::End;
},
Self::End => {
panic!("poll () shouldn't be called after future is completed");
},
_ => unreachable!(),
}
// End of match statement.
Each time poll () is called, you do work and potentially shift into a different state.
Awesome videos, man. I'm not getting enough free time to learn Rust, nor getting a chance to use it at work. But I hope someday it will happen.
This was incredibly helpful. Thanks!
Would it make sense to have something like off-CPU analysis with bpf for futures on tokio executor? Some async-aware instrumentation might be able to hook into yield points and probe stack traces also saving timestamps.
Yup, I think there's been some talk about that already. Possibly by having a tracing subscriber that introduces labels that you can then refer to from bpf too. It's a tooling ecosystem that's very much still in its infancy though!
At 57:00, it's mentioned that if there's a future that's blocking on something that takes forever, (and therefore never yields), nothing ever gets the chance to run. But stuff can still run on another thread right? (Assuming the chosen tokio runtime is multithreaded?
Yep, I talk about that a little later in the video. The devil is in the details here though. For example, Tokio implements (at least, implemented) an optimization that makes it faster to schedule a future that recently ran, which in turn makes that future not possible to steal. So if you block an executor thread, you _also_ block that additional future. Which may in turn prevent other futures from running that depend on that future running. Basically, blocking the executor can have grave and unexpected consequences, so don't do it 😅
@@jonhoo noted. So what I'm gathering so far is that it's fairly easy to reap the full benefits of async/await as long as you adhere to a few simple rules
This is so awesome. I finally know how to handle the issues that I have met with async in Rust.
@32:52 "every await is an opportunity to chose to do something else". I assume this is only true if the awaited future is not immediately ready (im thinking of `std::future::ready()`) ?! I.e. futures are eagerly progressed, if possible. Only if there are some special os or async-framework specific calls controll will be yielded and other futures may progress. Is that correct?
No, futures are *not* eagerly professed. The executor is allowed to to run the same future again, but is under no obligation to do so. And generally it'll take the opportunity to run another future instead.
@@jonhoo thanks :)
Thanks for the video, really helpful!
Is there a reason Tokio itself reimplements the std::fs functions directly for example? Rather than having an executor-agnostic async standard library crate?
Because in general the I/O resource types (like TcpStream) need to communicate with the executor in order for the executor to know what events to wait for when it decides to put a thread to sleep. And there is no executor-agnostic way to do that currently. We may eventually get something like that, but likely not any time soon.
If my async function does an IO in a very deep call stack, does it have a lot of overhead everytime the future is polled? Because the poll need to check the state of the top of the call stack, down to the last call stack that actually perform the IO.
really love your book, i am learn a lot.
2:13:00 I feel there needs to be a way to get a warning when calling a blocking function in an async function. It would solve exactly these kinds of problems. I will have to look into it.
Thank you alot for these streams, this one realy helped me in learning async 👍👍👍🙏🙏🙏❤❤
It's funny, coming from JavaScript, conceptualizing futures and async await feels natural. It's threads that confuse me yet it looks like most people in the comment section are in the opposite camp
5 stars, well done.
Good stuff for hardcore C++ coders other than just dummy hello worlds.. Big up!
Does anyone knows if there is any programming language that supports execution of async with multiple threads like rust?
Is anyone able to tell me whether anything has changed with async/await in rust since this video? Just wanting to confirm before committing the time
async fn in traits is now allowed and RFCs for async closures and naming the return type of (async) methods have been accepted.
Greate explanation, In Asynchronous mutexes you said that using standard library mutex for short operation is safe but I think it's true for single thread async app, But if we have more than 1 thread always there is a chance that two parts of code refer to same mutex that may lead to deadlock, certainly in short operation this chance is very low but it's still possible.
Perfect timing!
I know it's a big topic, but I want to dive deeper in how unix based systems actually handle async events and parallel operations. At the very least I want to understand what the basic level async facilities are (network calls, file operations, what else could be async??). Do you have recommendations for materials on this topic?
This is very useful even though I don't use rust, only c++. This will definitely help for when I make my own multithreaded async yield system using c++20 co routine features. (With c++20 modules features, too. Let's see how many compiler bugs I will hit!)
brilliant explanations
How relevant/up to date is the content in this vid? Has async in Rust changed a lot in 2 years?
Should still be pretty much up to date!
What an amazing video!
Wow it’s the missing guide on async/wait I’ve been looking for. Watch the full video in one go, every second of it worth it.
This was amazing.
Any reasonable threaded scenario would use a thread pool for handling clients, so it wouldn't be an issue and would (IMO) still be easier to understand. To me the async model feels weird, and hides what is going on more, which I don't consider really a good thing when there are multiple things going on. And it lets you be sure you have a thread per client (if you want that), whereas that's not the case in the async model, where I assume you are depending on some internal heuristics as to how many threads are being created and when. The thread pool based system has a much more controllable response time to connections.
A generic interface for waiting on things (and for things to make themselves waitable) of course is simple and obvious, and can be used in many ways, without the obfuscation of the async system. And for those things that you really are likely want to want to wait on already probably have OS level (and wrappable by the runtime) mechanisms to have them be done asynchronously and signaled, so you can easily make those waitable without any of the overhead of the async system.
As a cooperative multi-tasking, it's really not useful for latency sensitive operations, except when everything it does is truly async and very light weight, and if you have to carefully ensure such things, what have you really gained in terms of simplicity? And how easy would it be for code changes to introduce something not light weight without it being at all obvious from reading the code?
If you have a thread pool / green threads, you already are in the woods of cooperative multitasking. All the technical drawbacks of async/await apply, and the choice is simply about taste/style. If you want true OS threads it proves to be too much of an overhead (for example Apache) to be competitive against an async/await high performance server (e.g. Nginx)
And yes, it is true that async await and coroutines in general is only good if your application is really low on compute, and dead heavy on IO, but that is really what a web server is, for like 99% of the time
@@cat-.- And there are now many web servers in the world, meaning real ones that need huge I/O throughput, not simple ones in devices and such? They would be about 0.0001% or some such of applications. And could still achieve the same thing even lighter weight than green threads by directly using async I/O.
Is there much support for debugging with async in rust? I'm not able to get break points to trigger in async functions.
Thanks Jon, learnt a lot!
So, with future and async/await, non blocking IO can be possible with only one thread? Or, is It possible without support of future and async/await ?
So under the hood, rust, go, and other co-routine-like features are still using EPoll on Linux, kqueue on Mac, IOCP on Windows.
If a executor have 2 future spawned and are in epoll ready, one's f.poll() return Ready and done. How will the executor return the ready value to the .await. and will/if it continue after .await on that future?. or will it wait for 2nd future.
Great talk! 👏
Fantastic talk - the only thing I would say is missing is more detail on how to deal with dynamically sized selects (i.e. the number of futures varies over time). Are Futures(Un)Ordered involved or tokio streams?
Thanks for the brief
I'm interested in your vim configuration -- what extensions are you using & how did you set up your dev environment so nicely!?
In the functional programming world we put our "effectful" operations in an "effect" type (Like cats IO in Scala)... so is it fair to say that in the Rust world, corresponding idea is to use futures and async/await?
Ah, no, this isn't a way to describe whether an operation does I/O or not. Synchronous code can also do I/O. It is solely a matter of using a different execution model.
@@jonhoo thanks!!
This is probably a very stupid question, but in foo2() why do you want to “sleep” until a future is resolved? I mean why not just block? What’s the benefit of going to “sleep” and being woken up by the OS if you’re in a non UI environment like a CLI? Is it because you’d save on computational cycles that would normally be wasted? Again, sorry if it’s a stupid question. I understand the use case with select!, but not in a “regular” code.
Great video. Thanks for sharing.
I didn't get a YT notification for this :(. I would have liked to ask whether it was normal for tokio select! to poll without being explicitly notified by a waker? I have a delay_queue the impls Future and it gets several extra calls to poll by select! before select! actually sleeps and waits for the waker. It feels kinda like debouncing.
I would expect it the poll function to be called twice. Once on init and then finally when the waker notifies the executor and the future completes...
So are futures Rust's answer to green threads? if not, what is the difference between green threads and Rust futures?
Well, sort of. Futures aren't themselves green threads, since they don't actually run on their own, but when combined with an executor you effectively get green threading.
@@jonhoo makes sense, thanks!
Man, i wish you run the programs you wrote. Content is great but seeing them in action makes me understand the process better.
I'm curious what you feel like that would add in this video? I usually do run my code, but here most of what I've written is more about the types, and running it wouldn't actually print anything 😅 For much of it, there'd also be a bunch of not particularly interesting extra code to write to get things to compile, which would make the video probably twice as long without actual contributing any further insights or understanding.
Hi, do you often do rust lives like this ?
Hello, I saw your video on TH-cam above and thought it was very good. I am from China and would like to translate your video into Chinese subtitles for Chinese video sites, what authorization do I need?
Hi there! You don't need any authorization. The videos are licensed under Creative Commons specifically for this purpose. Please provide a link back to the video and/or to my Twitter though :)
With the select! macro, lets say I have 2 things that I'm waiting on. The first is a TCP socket that gets data from the network in a highly variable manner. Sometimes I get packets from it between 1 second to 1 hour. (This also means that I have to keep the connection alive by sending it a ping to the server every 30 seconds.) The second is a UDP socket that gets data from the network in a much more consistent manner. I get a packet from there between 50 milliseconds to 6 seconds. Both of these packets are getting parsed out and saved to different SQLite databases on the backend. The TCP one is doing a lot of computation on that packet and indeed could make another TCP connection to another server, or send a HTTP request to another service this takes a lot of time. Is there a guarantee within the runtime that the if I get another TCP packet or UDP packet before that computation is done that it will also handle the next TCP packet as well? Or am I going to spill the next packet on the floor as it flows past what my program is able to handle. What about the UDP side that is waiting for TCP to handle its packet. Given that the TCP side could take several seconds to finish its processing of that packet, would I be dropping UDP packets on the floor because my TCP future is running and hogging the system?
Partially answered at 55:35 - You would need to call .await on these expensive functions call in the TCP socket to make sure that it yields back to the select call. What it does't answer is if another TCP packet comes in, would that TCP packet get processed as well, or would the new TCP packet clobber the handling of the previous packet that is still in flight, or would it drop that packet, or would it queue the packet for the next iteration into the select macro call. -- The solution (but not the answer) for that comes at 1:27:00 where they talk about giving that packet (or connection in their example) to the executor for them to handle and make progress on until it's done.
I considered rust for writing a highly asynchronous I/O heavy application, however I ran into trouble when I was trying to await on a few lists of futures of different types. Additionally, at the end of a task from a list sometimes I would add some more to one of the other lists, meaning that I had to really select on these lists and depending on which task was finished, possibly modify these lists. I am new to Rust so I don't know if I was missing something but I found no way to do just that (selecting on multiple lists of different types of futures), do you know if / how it could be done?
The way I'd do this is to tokio::spawn each future, and then add all the returned join handle futures to a FuturesUnordered which you can then pull from.
@@jonhoo Thanks, I used std async just because I thought it's the standard having std in the name :)). But I see tokio is really the most used and fully featured one, I'll try again with tokio and see what results I get.
So if you only ever use await and never spawn or join, the program behaves sequentially?
I feel really weird that the futures don't really execute until .await is called on them, while there is a background worker thread that could've taken that future and polled it to completion. Are there any executors that immediately start polling the future (in a background thread) as soon as they are made? (Eg: the future in its construction pushes itself to a worker_queue that the executor pops the futures out of and distributes them to worker threads).
This model of not executing a future immediately only works if you have a lot of futures to poll/execute so that the background thread isn't really wasting time when the future wasn't .await-ed .
No, there is no such executor. And there couldn't be - there's nothing special about the creation of a future that an executor could hook into. In fact, even await doesn't actually make a future run. It just says that *when* this future runs, and gets to this point, it must wait for this other future. It's only when a future is given to an executor that it actually runs.
@@jonhooWell yes, you are right in that Rust doesn't have some notion of "default constructor" that gets run, which would've made this elegant. However at the expense of more boilerplate, couldn't we write an extension method on Futures, say .run(), that spawns the future in a new Task/parallel compute, and returns some sort of handle that you can call .await on? Would it be possible to do this without too much synchronisation problems?
The windows IO thing is IO completion ports IIRC
Great channel. Found your reference from the Demikernel paper.
What is this Vim setup anyway? Looks great
Never seen the "select" macro, the JS way would be to add .then() on each promise and then do Promise.all(). That way, you can still react to each individual promise resolving but you also have guarantee that the process will not continue until all promises have resolved.
Not sure how that would work in Rust. Event if you added a .then() function on a future, I guess there might be some complications with the borrow checker. I will have to try it out to find out.
2 streams in 1 day? Christmas came early :)
A Masterclass
Just bought your book.
I love the syntax highlighting here, is this a popular vim color scheme?
It's called base16-gruvbox-dark-hard
Awesome tutorial!
github.com/jonhoo/configs/blob/master/editor/.config/nvim/init.vim :)
With C++ futures, its interesting to note that there is different behavior:
#include
#include
auto f() -> std::future {
return std::async(std::launch::async, [] {
std::cout
"rejiggered" ...i'm stealing this
What’s the difference between tokio::spawn and spawn_blocking?
Thank you for your videos.
How do panics work in async code? Can you catch panics from a spawn or something?
Depends on the executor. I believe Tokio will generally catch panics to prevent the executor threads from terminating, and then propagate that to join handles, but the documentation should say.
What are you typing on? Looks like vim. Where can I look it up?