Crate rayon_core [−] [src]

Restricting multiple versions

In order to ensure proper coordination between threadpools, and especially to make sure there's only one global threadpool, rayon-core is actively restricted from building multiple versions of itself into a single target. You may see a build error like this in violation:

error: native library `rayon-core` is being linked to by more
than one package, and can only be linked to by one package

While we strive to keep rayon-core semver-compatible, it's still possible to arrive at this situation if different crates have overly restrictive tilde or inequality requirements for rayon-core. The conflicting requirements will need to be resolved before the build will succeed.

Structs

Configuration	Contains the rayon thread pool configuration.
Scope
ThreadPool

Functions

current_num_threads	Returns the number of threads in the current registry. If this code is executing within a Rayon thread-pool, then this will be the number of threads for the thread-pool of the current thread. Otherwise, it will be the number of threads for the global thread-pool.
current_thread_has_pending_tasks	If called from a Rayon worker thread, indicates whether that thread's local deque still has pending tasks. Otherwise, returns `None`. For more information, see the `ThreadPool::current_thread_has_pending_tasks()` method.
current_thread_index	If called from a Rayon worker thread, returns the index of that thread within its current pool; if not called from a Rayon thread, returns `None`.
initialize	Initializes the global thread pool. This initialization is optional. If you do not call this function, the thread pool will be automatically initialized with the default configuration. In fact, calling `initialize` is not recommended, except for in two scenarios:
join	The `join` function takes two closures and potentially runs them in parallel. It returns a pair of the results from those closures.
scope	Create a "fork-join" scope `s` and invokes the closure with a reference to `s`. This closure can then spawn asynchronous tasks into `s`. Those tasks may run asynchronously with respect to the closure; they may themselves spawn additional tasks into `s`. When the closure returns, it will block until all tasks that have been spawned into `s` complete.