https://github.com/njaard/pond
Rust: A scoped threadpool where each thread has a state
https://github.com/njaard/pond
crates rust thread-pool
Last synced: 8 months ago
JSON representation
Rust: A scoped threadpool where each thread has a state
- Host: GitHub
- URL: https://github.com/njaard/pond
- Owner: njaard
- Created: 2017-11-19T13:50:58.000Z (over 8 years ago)
- Default Branch: master
- Last Pushed: 2020-04-10T15:25:03.000Z (almost 6 years ago)
- Last Synced: 2025-06-20T14:21:33.069Z (8 months ago)
- Topics: crates, rust, thread-pool
- Language: Rust
- Size: 16.6 KB
- Stars: 13
- Watchers: 1
- Forks: 1
- Open Issues: 1
-
Metadata Files:
- Readme: Readme.md
Awesome Lists containing this project
README
[](https://raw.githubusercontent.com/njaard/pond/master/LICENSE)
[](https://crates.io/crates/pond)
[](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) (Original inspiration for this crate. Has a very similar API, but no state).
* [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)