Under the hood, does the upcoming async/await implementation use a thread pool or does it spawn a new thread for each async call?
When you use the async/await mechanism, you need to pick a runtime. A runtime is the code that actually runs the futures, and it is not part of the standard library.
The classic example of a runtime is the tokio crate, which provides two options: A thread pool and a single threaded executor.
2 Likes
I am no export on this but I think the point with async/await is better utilization of available CPU without the synchronization overhead when You spawn new threads.
1 Like
The entire point is to avoid spawning threads for each async call. All implementations are either single-threaded or use a thread pool.
2 Likes
Somebody recently summed up threads vs async like so: "Threads are for doing a lot of work at the same time, Async is for waiting for many things at the same time"
This is to say, if you have a lot of actual compute work to do you need threads, those threads can be spread over your cores and you work gets done quicker.
On the other hand if you need to wait for input from a million connected web sockets or database queries etc then you don't want the overheads of spinning up a million threads just to wait on all those blocking calls. That's a lot of memory wastage in thread stacks an the like and a lot of time wasted in context switching.
I conclude that somewhere in between we want Async to do all that waiting, but we also want to spread that over a pool of threads so that our cores can be used effectively.
So far, what I see of Async in Rust is giving me headache. It's so much clearer in Javascript where event driven programming is there naturally in the language.
2 Likes
So, when this is released in Rust 1.39, it will not actually be part of the standard library?
Not every piece is part of the standard library. The standard library contains the parts that must be there for the new language features to work (e.g. we must have the Future trait for an async fn to even make sense), but some other pieces of the puzzles wont be.
There are several good reasons for this, but the biggest one is that if you make a mistake in the design of something in the standard library, you have to support it basically forever because of backwards compatibility. We will probably see some of the things be moved from crates into the standard library in the future, but initially it contains just what has to be there.
3 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.