Struct ThreadPool

pub struct ThreadPool { /* private fields */ }

Thread pool for running compute-intensive tasks in parallel.

Note that the tasks are run in submission order (on multiple threads, if available), so a task that e.g. blocks on a file read will prevent other tasks from running.

Implementations

impl ThreadPool

pub fn new(threads: Box<[ThreadState]>) -> Option<ThreadPool>

Creates a new ThreadPool, returning None if the channels don’t have matching capacities.

pub fn thread_count(&self) -> usize

Returns the amount of threads in this thread pool.

pub fn queue_len(&self) -> usize

Returns the length of a task queue.

In total, tasks can be spawned without joining up to this amount times the thread count.

pub fn has_pending(&self) -> bool

Returns true if the thread pool has any pending tasks in the queues.

pub fn reset_thread_counter(&mut self)

Resets the counter used to assign tasks to different threads.

After calling this, the next ThreadPool::spawn_task is sent off to the first thread, instead of whichever value the counter is on now.

pub fn spawn_task<T>( &mut self, data: Box<T>, func: fn(&mut T), ) -> Result<TaskHandle<T>, Box<T>>

Schedules the function to be ran on a thread in this pool, passing in the data as an argument, if they fit in the task queue.

The function passed in is only ever ran once. In a single-threaded environment, it is ran when join_task is called for this task, otherwise it’s ran whenever the thread gets to it.

The threads are not load-balanced, the assigned thread is simply rotated on each call of this function.

Tasks should be joined (ThreadPool::join_task) in the same order as they were spawned, as the results need to be received in sending order for each thread. However, this ordering requirement only applies per-thread, so ThreadPool::thread_count subsequent spawns can be joined in any order amongst themselves — whether this is useful or not, is up to the joiner.

pub fn join_task<T>( &mut self, handle: TaskHandle<T>, ) -> Result<Box<T>, TaskHandle<T>>

Blocks on and returns the task passed into ThreadPool::spawn_task, if it’s next in the queue for the thread it’s running on.

The Err variant signifies that there’s some other task that should be joined before this one. When spawning and joining tasks in FIFO order, this never returns an Err.

Depending on the ThreadStates passed into the constructor, this could either call the function (if it’s a one-channel state), or wait until another thread has finished calling it (if it’s a two-channel state that actually has a corresponding parallel thread).