# `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.

```rust
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](https://docs.rs/employees/latest/employees/) 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](https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/).

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`](https://docs.rs/rayon/latest/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](LICENSE) for details.