4 ms·
The 'simple' adjective is vastly abused - in majority of cases code behind 'simple' project isn't simple - like in this case a person without mid-advanced knowl
by trzeci 7y ago
The 'simple' adjective is vastly abused - in majority of cases code behind 'simple' project isn't simple - like in this case a person without mid-advanced knowledge about threading / binding / synchronisation / generic programming will have a problem to grasp what's going on in the implementation.
Side note is that I love how rust simplified that (https://docs.rs/threadpool/1.7.1/threadpool/ https://docs.rs/threadpool/1.7.1/threadpool/).
- mschuetz 7y agoIt's simple as in simple to use. Something that C++ needs more of.
- jupp0r 7y agoNo it's not. It looks like it on the surface, but real world usage will run into the blocking `get()` methods blocking threads on the thread pool leading to deadlocks or low throughput. What C++ needs is a well thought out design of how to transfer values in a purely asynchronous manner (like Rust futures, JavaScript promises, etc).
- MaxBarraclough 7y agoIs that kind of thing a concern in other thread-pool implementations too?
- jupp0r 7y agoThe thread pool normally just allows you to execute code (think void() lambdas). Returning values to the caller isn’t something they normally do, but is normally managed by higher level concurrency libraries like facebooks folly or libq (among others).
- MaxBarraclough 7y agoAh yes of course, auto result = pool.enqueue.... is blocking. Oh dear.
- jupp0r 7y agoThe assigment isn’t, but result.get() is (potentially, if computation hasn’t finished yet).
- MaxBarraclough 7y agoAh yes, I skimmed the code too quickly. Again :-P 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.
- MaxBarraclough 7y agoNo, that isn't what it's aiming for. GitHub project description: > A simple C++11 Thread Pool implementation
- mschuetz 7y agoIt's very obviously not refering to the implementation but to how it's used, no need to be pedantic.
- steveklabnik 7y agoThe threadpool crate is great, but there is a lot more going on with it than this library. 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.html 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&edition=2018&gist=0a2248e959e8f1d499f4fe4ed1c86f63 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.