5 ms·
It's simple as in simple to use. Something that C++ needs more of.
by mschuetz 7y ago
It'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.