Get the global thread pool repeatedly (to pass to a function)

[kno10]

Assume I am writing a library with a function

fn lots_of_work(&pool: ThreadPool) {
  pool.scope(|s| { s.spawn( ... ); })
}

where the responsibility of configuring and selecting the thread pool is delegated to the caller.

The user can use the global thread pool via

let pool = rayon::ThreadPoolBuilder::new().build_global().unwrap();
lots_of_work(&pool)

but this can only be called once, because build_global() fails if used a second time.

But I do not want the user to have to create a new thread pool every time, either.

What is the best way to allow the user to call the function with the default thread pool?
I could not find something like

lots_of_work(rayon::get_global_threadpool())

where the user does not need to track his reference to the global pool forever.

[cuviper]

The user can use the global thread pool via

let pool = rayon::ThreadPoolBuilder::new().build_global().unwrap();
lots_of_work(&pool)

This doesn't work even once, because build_global() doesn't give you a pool handle at all.

One thing you can do right now is make the pool argument optional:

fn lots_of_work(pool: Option<&ThreadPool>) {
    if let Some(pool) = opt_pool {
        pool.scope(|s| do_scoped_work(s))
    } else {
        rayon::scope(|s| do_scoped_work(s))
    }
}

However, a caveat is that rayon::scope will use the current pool, which may not be the global pool if you're already running in a pool thread. That might be a useful semantic for you anyway, but there's not currently a way to force use of the actual global pool from any arbitrary context.

See also #841 proposing to expose the current pool handle, and we could possibly do similar for the explicit global pool.

[kno10]

Does this mean that if the user did

pool.scope(|s| do_scoped_work())

fn do_scoped_work() {
  rayon::scope(|s| ...)
}

then rayon::scope would use the pool configured before and not the global pool? That would be fine, as there is no need to switch between multiple pools in my code.

[cuviper]

Correct, rayon::scope will use whatever pool you're currently in, or else the global pool as a fallback.

[cuviper]

The user can also call pool.install(|| do_scoped_work()) to avoid the extra scope machinery.

[kno10]

Maybe this could be clarified in the documentation.
E.g., the documentation of rayon::spawn says "Fires off a task into the Rayon threadpool in the “static” or “global” scope."
I assume this also rather uses the thread's current scope then, and not the global scope (unless there is no more local scope)?

[cuviper]

Hmm, I think the point rayon::spawn is trying to make is more about how that runs detached in the pool, compared to Scope::spawn that is still detached but bounded by the scope. It's not really talking about which pool there, but it should probably avoid the word "global". (It might have predated support for non-global pools in the first place.)

Documentation improvements are always welcome!

[baszalmstra]

I am using a library that is using rayon. I want to initialize the threadpool in a specific way (e.g. number of threads), and I want to do this as late as possible to incur overhead only when we need the threads. However, when I initialize it too late the threadpool might be initialized by code of a dependency.

I figured it would be nicer if I could pass an explicit thread pool to use to dependencies (or use install) to wrap them. However, since I cannot explicitly pass the global thread pool this is a bit tricky.

Would it be possible to have function as OP suggested:

rayon::get_global_threadpool()

At least we could be explicit about it then!

[baszalmstra]

Any word on this?