rayon-rs / rayon

Rayon: A data parallelism library for Rust

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

use_current_thread and the global thread pool

m-mueller678 opened this issue · comments

Is there a way to prevent the main thread from participating in the global thread pool? It seems to be included even without calling ThreadPoolBuilder::use_current_thread ?

use std::time::Duration;

fn main(){
    rayon::ThreadPoolBuilder::new().num_threads(2).build_global().unwrap();
    println!("main thread {:?}",std::thread::current().id());
    rayon::scope(|s|{
        for tid in 0..10{
            s.spawn(move|_|{
                println!("task {tid} sleeping on {:?}",std::thread::current().id());
                std::thread::sleep(Duration::from_secs(1));
                println!("task {tid} done");
            });
            println!("task {tid} spawned");
        }
        println!("scope sleeping on {:?}",std::thread::current().id());
        std::thread::sleep(Duration::from_secs(3));
        println!("scope done");
    });
}

playround

In this example, one tasks runs at a time. When the sleep in scope completes, two tasks are run at a time, one on the main thread and one on an additional thread. I would expect that there are two threads in addition to the main thread. If this is intended behavior, I think the documentation around ThreadPoolBuilder should make this more clear.

rayon::scope runs its closure within the pool -- this is its main distinction versus in_place_scope. Your playground even shows this by ThreadId numbers, where main is 1 and the pool (including the scope) run on 2 and 3. Your main thread is entirely blocked until it all finishes.

https://docs.rs/rayon/latest/rayon/fn.scope.html

The closure given to scope() executes in the Rayon thread-pool, as do those given to spawn().

https://docs.rs/rayon/latest/rayon/fn.in_place_scope.html

This is just like scope() except the closure runs on the same thread that calls in_place_scope(). Only work that it spawns runs in the thread pool.

You are right, I must have misread the output from the playground. Confirmation bias, I guess. I missed the part about the closure being run in the thread pool and thought it would be like std's.