[Lldb-commits] [PATCH] D13727: Add task pool to LLDB

[Todd Fiala via lldb-commits]

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.



http://reviews.llvm.org/D13727