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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
