Struct burst_pool::BurstPool [] [src]

pub struct BurstPool<T> { /* fields omitted */ }

A thread pool optimised for bursts of activity.

A BurstPool maintains one unbounded channel for each thread. Because these channels have only one producer, the more efficient spsc implementation will be used.

Threads spawned in the pool are parked (they do not busy-wait) until there is work to be done. When BurstPool::send() is called, a thread is chosen, the payload is pushed onto its queue, and it is unparked. Threads are selected round-robin, so uneven processing time is not handled well.

When the BurstPool is dropped, all threads will be signalled to exit. Dropping will then block until the threads are all dead.

If a thread panics it will go undetected until we attempt to send some work to it. At this point, the thread will be removed from the pool and a warning will be issued, and the work will be sent to the next thread in the ring. Dead threads are not replenished.

Example

use burst_pool::BurstPool;

let mut pool = BurstPool::new();

for thread_id in 0..3 {
    pool.spawn(move|x| {
        println!("Thread {} received {}", thread_id, x);
    });
}

for x in 0..5 {
    pool.send(x).unwrap();
}

This will print something like:

Thread 0 received 0
Thread 0 received 3
Thread 1 received 1
Thread 1 received 4
Thread 2 received 2

Methods

impl<T> BurstPool<T> where
    T: Send
[src]

Create a new empty pool.

Spawn a thread in the pool.

The spawned thread blocks until pool.send() is called, at which point it may be woken up. When woken, it runs the given closure with the value it recieved, before going back to sleep.

Since you typically don't know which thread a send() call will wake up, all workers in a pool should do pretty similar things with the work they receive. Also, bear in mind that the BurstPool's scheduling strategy doesn't cope well with uneven processing time - particularly when one thread is systematically slower than the others.

Send a value to be processed by one of the threads in the pool.

If there are no threads available to perform the work, an error is returned containing the unperformed work.

Trait Implementations

impl<T> Drop for BurstPool<T>
[src]

Signal all the threads in the pool to shut down, and wait for them to do so.