pond 0.3.1

A library for scoped and cached threadpools that keep a state.
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81

[![GitHub license](https://img.shields.io/badge/license-BSD-blue.svg)](https://raw.githubusercontent.com/njaard/pond/master/LICENSE)
[![Crates.io](https://img.shields.io/crates/v/pond.svg)](https://crates.io/crates/pond)
[![Documentation](https://docs.rs/pond/badge.svg)](https://docs.rs/pond/)

	[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](https://crates.io/crates/scoped-threadpool) (Has a very similar API, but no state). Please beware [a serious bug](https://github.com/Kimundi/scoped-threadpool-rs/issues/16).
* [scoped_pool](https://crates.io/crates/scoped_pool) (Very flexible, but no state)
* [crossbeam](https://crates.io/crates/crossbeam) (doesn't implement a thread pool)