7 releases
0.1.0 | Sep 23, 2024 |
---|---|
0.0.6 | Apr 8, 2024 |
0.0.4 | Dec 15, 2023 |
0.0.3 | Nov 21, 2023 |
#247 in Concurrency
203 downloads per month
67KB
874 lines
employees
A small and lightweight crate to hide most of the burden of setting up long-living threads.
Philosophy
This crate sees threads as unique entities called workers
which may (or may not) live as long as the program lives. Workers
are spawned in Runtimes
that manage them.
Usage
Here's a small example that spawns a worker that prints "Hello, World!" every 100ms for 1 second.
struct WorkerThatPrints;
impl Worker for WorkerThatPrints {
fn on_update(&mut self) -> ControlFlow {
println!("Hello, World!");
std::thread::sleep(Duration::from_millis(100));
ControlFlow::Continue
}
}
let mut runtime = Runtime::new();
runtime.launch(WorkerThatPrints);
std::thread::sleep(Duration::from_secs(1));
See the full documentation for more in depth details.
Should I use employees
?
Concurrency
employees
is built with CPU-bound concurrency in mind.
"But wait, arent't async runtimes built for that purpose?" you might ask, and you'll be 100% right.
However, async
has drawbacks which employees
hasn't:
- async tasks must not be blocking,
- the famous colored function problem.
That said, there are usecases where async runtime will be better such as I/O bound tasks (web servers, ect.) or concurrent tasks on single threaded platforms.
Paralellism
Again, employees
is built with concurrency in mind. While it is possible to build a work stealing thread pool from employees
to parallelize some kind of computation, other crates such as rayon
add a ton of utilities speficically made for that purpose which is why, for most paralellism usecases, rayon
-like crates will be a better choice.
License
Licensed under the terms of MIT license. See LICENSE for details.
Dependencies
~0.2–6.5MB
~37K SLoC