[Lldb-commits] [PATCH] D13727: Add task pool to LLDB
Todd Fiala via lldb-commits
lldb-commits at lists.llvm.org
Thu Oct 15 09:49:53 PDT 2015
tfiala added a subscriber: tfiala.
tfiala added a comment.
In http://reviews.llvm.org/D13727#268053, @zturner wrote:
> The main thought I had was just that it would make the code simpler and delegate more of the synchronization stuff to the library. But if we don't get any of that benefit then I guess there's no point in doing that.
> That said, I really dont' want to see 48 threads running inside the LLDB process at all times (I have a 48-core machine). It makes it really annoying to debug. So some way to tear down threads would be a big help. But that's even more complexity.
> If this is only going to be used occasionally (like each time some DWARF is being parsed), then what about making `TaskPool` non-static? Just create a new TaskPool each time you want to do work in parallel and tear it down when you're done doing the work? If someone creates 2 task pools they get 2 different sets of threads. This is kind of why I prefer delegating to the standard library whenever possible, because it shoudl already handle all of these cases.
Ooo - danger lies down that path. We don't want different parts of lldb that can be thread-ized (and there are several of them) all doing work as if they have all the threads available to them. That should be managed by a global thread pool for the app. I think we'll see much more use of this facility once we have it in.
> Another option is to go back to the original one line implementation using std::async, but have each asynchronous thread work on `num_compile_units / hardware_concurrency()` compile units inside of a loop. That way you never get more than `hardware_concurrency()` threads.
More information about the lldb-commits