<div dir="ltr">Then make it ready :-/<div><br></div><div>Why does LLDB need llvm::ThreadPool for this to work?  I proposed a single function that is not dependent on any particular instance of a thread pool.  </div><div><br></div><div>template<typename Range, typename Func></div><div>void parallel_for_each(Range &&R, Func &&F) {</div><div>  // call F(Index, *Iter) for every item in R.</div><div>}</div><div><br></div><div>std::vector<std::string> Foos = { "a", "b", "c" };</div><div><br></div><div>void handle_foo(int N, const std::string &S) {}</div><div><br></div><div>llvm::parallel_for_each(Foos, handle_foo);</div><div><br></div><div>There's nothing that needs to be done here to make this ready for llvm::ThreadPool, because all you have to do is use it.  </div><div><br></div><div>Perhaps the function could create a llvm::ThreadPool on the stack to be used for this one operation.</div><div><br></div><div>Perhaps llvm is willing to allow a single global thread pool to be created for parallel operations, and entire library of parallel functions could be added that use the same global thread pool.</div><div><br></div><div>Or maybe we could have llvm::initializeParallelThreadPool(unsigned Concurrency) that specifies the number of threads to create and all operations will use that global thread pool.</div><div><br></div><div>The point is, without even making an effort to try, we don't know what issues will people will have or how hard it even is.  It might end up being trivial, and you would get a lot of valuable performance and safety feedback from some very good experts on the subject.</div><div><br></div><div>I'm not stating an ultimatum that the only way this will go in is if it's in LLVM, but I *am* stating that LLVM needs to be the starting point for discussion here, and only after we discover (if we discover) that a solution cannot work, we can revisit this in LLDB.</div><div><br></div><div>This is useful functionality that could be used everywhere, and I would like to see due diligence done here.</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, May 2, 2017 at 1:56 PM Scott Smith via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">scott.smith added a comment.<br>
<br>
In <a href="https://reviews.llvm.org/D32757#743796" rel="noreferrer" target="_blank">https://reviews.llvm.org/D32757#743796</a>, @zturner wrote:<br>
<br>
> s/instead of LLVM/instead of LLDB/<br>
<br>
<br>
I hear you, but IMO it's not ready for that yet.<br>
<br>
1. It would depend on ThreadPool, but<br>
2. LLDB hasn't switched to ThreadPool yet, because<br>
3. I want to figure out how to incorporate tasks enqueuing tasks first.<br>
<br>
I don't want to commit a monolithic patch with all my changes (and I haven't developed them all yet), so instead I submit incremental improvements.<br>
<br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="https://reviews.llvm.org/D32757" rel="noreferrer" target="_blank">https://reviews.llvm.org/D32757</a><br>
<br>
<br>
<br>
</blockquote></div>