[dependencies]
pond = "0.3"

Introduction

Yet another implementation of a scoped threadpool.

A scoped threadpool allows many tasks to be executed in the current function scope, which means that data doesn't need to have a 'static lifetime.

This one is has the additional ability to store a mutable state in each thread, which permits you to, for example, reuse expensive-to-setup database connections, one per thread. Also, you can set a backlog which can prevent an explosion of memory usage if you have many jobs to start.

Usecase

If you need to make multiple connections to a database server, without this crate, you need some sort of connection pooling library, and therefor each connection needs Rust's Send capability. Furthermore, there's no guarantee that your connection pooler will keep the connection on the same thread.

With this crate, you provide a function that sets up the connection, then the function is called in each thread at initialization time. A mutable reference is passed to your job closures. It's your job's responsibility to make sure that each job keep the database connection in a sane state between jobs.

Using the state-making capability is optional. If you don't call the with_state function, then your job closures don't need any parameters, which therefor makes this crate compatible with other scoped threadpool libraries.

Example

extern crate pond;
let mut pool = pond::Pool::new();

let mut vec = vec![0, 0, 0, 0, 0, 0, 0, 0];

// Each thread can access the variables from
// the current scope
pool.scoped(
    |scoped|
    {
        let scoped = scoped.with_state(
            || "costly setup function".len()
        );
        // each thread runs the above setup function

        // Create references to each element in the vector ...
        for e in &mut vec
        {
            scoped.execute(
                move |state|
                {
                    *e += *state;
                    assert_eq!(*e, 21);
                }
            );
        }
    }
);

Changelog

• 0.3.0 (2018-07-09): The constructor for Pool now in general defaults to the native number of threads, and the backlog is no longer unbounded. I have found that this makes things less error prone and less unnecessarily verbose.

See Also

• scoped-threadpool (Has a very similar API, but no state). Please beware a serious bug.
• scoped_pool (Very flexible, but no state)
• crossbeam (doesn't implement a thread pool)