I'm really glad I found this video! Never done multithreaded anything and always assumed it would always be better if you could manage to do it without breaking anything but I see now that the simpler option might actually be better!
The main thing I'd like to know, is if there are particular functional discrepancies between the two, that would create exclusive use case for one over the other...
It seems that a lot has changed in the tokio API since this video was created. For example, it seems that using the "#[tokio::main]" attribute on the main function is now preferred and the shutdown_on_idle method is no longer supported. Here is my attempt at updating the code. Does this seem like the best alternative code? ```rust use rand::Rng; // trait that must be in scope use std::{thread, time::Duration}; use tokio::task; #[tokio::main(worker_threads = 4)] async fn main() { let mut handles = vec![]; for _ in 0..100 { // We must pass a Future to task::spawn. // Using an async block does this. handles.push(task::spawn(async { let ms = rand::thread_rng().gen_range(1000..2000); thread::sleep(Duration::from_millis(ms)); println!( "ms: {}, thread name: {}", ms, thread::current().name().unwrap() ); })); } for handle in handles { handle.await.unwrap(); } println!("done"); } ```
I'm afraid not! This functions very differently - by using thread::sleep inside an async task you are making the tokio worker thread go to sleep for a considerable period of time, which won't break your program per se but it can cause serious performance issues. If you are in an async context you should call tokio::time::sleep ( docs.rs/tokio/latest/tokio/time/fn.sleep.html ) to obtain a future and then await on it. This will put the task to sleep, freeing up the tokio worker thread to go and do something else.
I'm aware there's no such thing as a tool for all jobs. But, what would be a good example to *NOT* use tokio instead of using more threads? Probably when you have to do heavier work in a lot of threads that you know they will happen, instead of having a lot of threads that MAY or MAY NOT be used fully. But not really sure about it. Thanks!
The basic problems with threads are the stack memory required for each one, the creation overhead, and the context switching overhead. As a concrete example, I wrote a program called hashgood that calculates up to three hashes simultaneously on the same data. Since there will only be up to three, it made perfect sense to spawn one thread for each one. I get the parallelism I want, the thread costs are negligible compared with the actual computation, and it was extremely simple to implement. On the flip side, if you have lots of (or an unknown number of) small tasks, well in excess of the number of cores in your computer, then you will probably see efficiency improvements using a green threads system like tokio.
More threads are better when you have CPU intensive operations such as large calculations. Be aware that as long as you are running on a single computer, then the processing that is available is limited by your available CPU resources. Every core can only run 1 thread per core, or two if it is hyper-threaded (which does slow it down), so trying to run 1,000 CPU intensive threads at the same time on a 4 core system is just going to make all of them run slower as the computer is trying to run them in parallel. If you run on a limited thread pool then you can force some of the tasks to finish first, and delay the rest. You can always try to scale out to multiple computers and even serverless functions. Just remember that this can add a lot of latency which may slow things down further.
Great video, subscribed and "rang the bell". One thing that seems a bit dodgy to me is that you don't run the same code in each thread/task. In the first example, you are sleeping in the thread itself. In the tokio version, you are apparently using some built-in method to add a delay to running the task itself. This throws me off because while in this case it's a great example of something tokio provides for you, most of the time, you aren't going to have a built-in function within tokio that emulates all the work you originally would have done within your thread. I would love a video from you elaborating on this and showing more async demonstrations in the future. I'm sure it would help me and everyone in the rust community who likes small bite-sized videos like this. Looking forward to future videos, please keep it up in this format...this is perfect. Edit: just saw you have newer videos on the async subject. Watching now!
Exactly what I was looking for, thank you!
for _ in 0..=100 { // actually iterates 101 times
I'm really glad I found this video! Never done multithreaded anything and always assumed it would always be better if you could manage to do it without breaking anything but I see now that the simpler option might actually be better!
Now I understand that tokio can be used for reusing the threads(worker). But, what is the difference between tokio runtime and thread pool?
The main thing I'd like to know, is if there are particular functional discrepancies between the two, that would create exclusive use case for one over the other...
I think it reduces devlopment overhead a lot, especially in larger applications.
Since you don't have to worry about being efficient in thread creation.
It seems that a lot has changed in the tokio API since this video was created. For example, it seems that using the "#[tokio::main]" attribute on the main function is now preferred and the shutdown_on_idle method is no longer supported. Here is my attempt at updating the code. Does this seem like the best alternative code?
```rust
use rand::Rng; // trait that must be in scope
use std::{thread, time::Duration};
use tokio::task;
#[tokio::main(worker_threads = 4)]
async fn main() {
let mut handles = vec![];
for _ in 0..100 {
// We must pass a Future to task::spawn.
// Using an async block does this.
handles.push(task::spawn(async {
let ms = rand::thread_rng().gen_range(1000..2000);
thread::sleep(Duration::from_millis(ms));
println!(
"ms: {}, thread name: {}",
ms,
thread::current().name().unwrap()
);
}));
}
for handle in handles {
handle.await.unwrap();
}
println!("done");
}
```
I'm afraid not! This functions very differently - by using thread::sleep inside an async task you are making the tokio worker thread go to sleep for a considerable period of time, which won't break your program per se but it can cause serious performance issues. If you are in an async context you should call tokio::time::sleep ( docs.rs/tokio/latest/tokio/time/fn.sleep.html ) to obtain a future and then await on it. This will put the task to sleep, freeing up the tokio worker thread to go and do something else.
Thank you for this short video!
I'm aware there's no such thing as a tool for all jobs. But, what would be a good example to *NOT* use tokio instead of using more threads?
Probably when you have to do heavier work in a lot of threads that you know they will happen, instead of having a lot of threads that MAY or MAY NOT be used fully. But not really sure about it. Thanks!
The basic problems with threads are the stack memory required for each one, the creation overhead, and the context switching overhead. As a concrete example, I wrote a program called hashgood that calculates up to three hashes simultaneously on the same data. Since there will only be up to three, it made perfect sense to spawn one thread for each one. I get the parallelism I want, the thread costs are negligible compared with the actual computation, and it was extremely simple to implement. On the flip side, if you have lots of (or an unknown number of) small tasks, well in excess of the number of cores in your computer, then you will probably see efficiency improvements using a green threads system like tokio.
More threads are better when you have CPU intensive operations such as large calculations.
Be aware that as long as you are running on a single computer, then the processing that is available is limited by your available CPU resources. Every core can only run 1 thread per core, or two if it is hyper-threaded (which does slow it down), so trying to run 1,000 CPU intensive threads at the same time on a 4 core system is just going to make all of them run slower as the computer is trying to run them in parallel.
If you run on a limited thread pool then you can force some of the tasks to finish first, and delay the rest.
You can always try to scale out to multiple computers and even serverless functions. Just remember that this can add a lot of latency which may slow things down further.
Great video, subscribed and "rang the bell".
One thing that seems a bit dodgy to me is that you don't run the same code in each thread/task. In the first example, you are sleeping in the thread itself. In the tokio version, you are apparently using some built-in method to add a delay to running the task itself. This throws me off because while in this case it's a great example of something tokio provides for you, most of the time, you aren't going to have a built-in function within tokio that emulates all the work you originally would have done within your thread. I would love a video from you elaborating on this and showing more async demonstrations in the future. I'm sure it would help me and everyone in the rust community who likes small bite-sized videos like this.
Looking forward to future videos, please keep it up in this format...this is perfect.
Edit: just saw you have newer videos on the async subject. Watching now!
i guess Im kinda randomly asking but do anyone know a good website to stream newly released series online?
@Fabian Ledger Flixportal =)
@Terrell Isaias Thanks, I signed up and it seems to work :) I really appreciate it!!
@Fabian Ledger No problem =)
This helped out so much! I would love a link to a github gist of the code.
I write this code but it results in Error... i add rand = "*" as dependencies in cargo.tomel file but still getting error. need guidance
Thanks for sharing 👍
I've a question, can we say that Tokio/Rust is like Node's?!?
Hahah thank you sir, it never made sense to me but know I get it. 😄👍🏽
thankyou :)
thanks u
thx