Side note is that I love how rust simplified that (https://docs.rs/threadpool/1.7.1/threadpool/).
Incidentally, we build a small threadpool in the final chapter of the Rust book. Most of the implementation is described here, https://doc.rust-lang.org/nightly/book/ch20-02-multithreaded... with a bit in the following section. Here's all the code together: https://play.rust-lang.org/?version=stable&mode=debug&editio...
One difference between this pool and the library in the OP is that the OP's pool returns handles that you can use to get jobs out of the pool, whereas this one does not. You can add that functionality on top of this pool by capturing a channel, but it's nice that they have it built in. It's not needed for the example I wrote the pool of, which is handling HTTP connections, so I didn't put it in there.
Looking at this example makes me wonder if I can simplify this even further; it’d be nice to remove that ref count. Not for performance reasons, just to make there be even less code.
The result local holds a future/task, not the result itself, and get() may force a synchronous wait, like Task#Result in .Net.
Somewhat related ramblings: I couldn't have misread the code in this way were it not for C++'s new type-inference with auto. In C#, I generally only use type-inference when first writing a statement, and then have the IDE substitute the var keyword to give a traditional 'explicit' declaration. Explicit types greatly help a codebase to be 'self-documenting'. Readability outweighs writing speed.
> A simple C++11 Thread Pool implementation