Rust tokio::task::spawn_blocking()? What is it good for?

A fellow youtuber has questions about what good spawn_blocking is. I hope I can help answer.
Vagelis:
• Rust: Exploring the To...
In depth on how Async/Await works in Rust
Jon Gjengset:
• Crust of Rust: async/a...
Thumbnail Image from Ryan Quintal
unsplash.com/p...

[@lume8476]

Does spawn blocking release the current thread? Or It just put the current thread in "wait" untill the blocking task is terminated?

[@masmullin]

There are two async/await concepts needed to explain this. Task and Thread. A task is a set of work to be completed, a thread is the underlying mechanism used to complete that work. calling something like web::block(||get_users()).await.unwrap() will release the thread back to the Tokio Runtime, but it does not "release" the task. The task is "await"ing the return of web::block, but the tokio runtiime can use the thread which was running the task for other purposes until the await is complete.

[@lume8476]

@@masmullin yes, of course. But is It the Waker thread (not the current thread) that Is polling the async task checking for any update? Am i right?

[@9SMTM6]

Since you referenced both rayon and Tokio and their use cases. There's something I've been wondering, but I don't really have a need for it, so atm I can't justify spending time on it. But perhaps you can easily clear that up for me: How would you go about using both rayon and (something like) tokio? I mean because there might be contention between the threads of the Tokio thread-pool and the ones of Rayon, and/or other unforseen difficulties

[@masmullin]

I haven't used Rayon, the information about it being suggested for CPU bound tasks comes from blog posts, tokio docs and other publications I read while trying to figure out how to demonstrate the importance of tokio::spawn_blocking. Tokio's tutorial has guidance saying "If the only thing your application does is run computations in parallel, you should be using rayon. That said, it is still possible to "mix & match" if you need to do both." tokio.rs/tokio/tutorial I haven't seen any specific guidance on "how" to mix and match. As for contention, the thread contention would be down to the operating system, as the OS scheduler ultimately gets to determine which thread gets time on the CPU. It shouldn't be more 'interesting' than running a sole-tokio or sole-rayon project on a machine running a lot of other busy applications. As for contention on process memory for a mixed rayon-tokio application, Rust does a good job with providing channels for communication between the two, and enforcing mutexing for any global state access, and isn't any different than sharing process memory between a sole-tokio or sole-rayon or a manual use of std::thread::task.

[@9SMTM6]

@@masmullin Thanks for the answer btw! Yes, upon further reflection, unless one explicitly does very good benchmarks, it's probably best to let the OS figure out how to balance Rayon threads with tokio ones. Even with a lot of benchmarks one might find out the situation is so dynamic that any static partition is worse than potential thread contention.

[@karelhrkal8753]

Damn, calling blocking functions in async reminds me of a talk about iterators in Java, when Java 8 came out in 2014. Those iterators had a function like "process in parallel", and it was not recommend it to use it for async tasks. Why? Because the executor would put each task in a thread from the pool, but if the task was just stuck waiting for IO, it would block other tasks for running. I think we *really* need better differentiation between tasks that are blocked by IO, tasks that are awaiting IO, and tasks that are doing heavy computation and are limited by CPU speed.

[@klikkolee]

Do you think this is a fair summary of spawn_blocking? spawn_blocking sacrifices a small amount of performance for one part of the application to protect the performance of the rest of the application. To see the benefit of spawn_blocking in a benchmark, you need to benchmarks code paths which do not use spawn_blocking, and you need to do so while code paths which use spawn_blocking are running simultaneously.

[@letcodeitnow]

Thanks so much for putting out this content, really helpful. I await more of your Rust videos ☺