tberghammer added a comment. I thought a bit about the points raised by Todd and in general I am happy with overloading the system during testing with a very high number of tests as it will most likely help us to detect race conditions and based on my testing (on a 40 core Linux machine) it isn't make any measurable difference in testing time.
I am fine with the idea of creating a setting to specify the number of threads in the thread pool (even though I don't see any immediate use case for it) but implementing it isn't easy because in the current system all setting is owned by an instance of the Debugger class (explicitly or implicitly). Adding a setting there to limit the number of threads will require the thread pool to get a reference to the Debugger instance what isn't a feasible solution. (Who would pass the Debugger to the thread pool? What happens when we have multiple debuggers?). The best solution currently I can think of (but I don't like) is to specify the maximum number of threads with an environment variable so it can be set before starting LLDB but it isn't a nice interface and using it when LLDB is loaded as a library is also problematic. My preference would be to commit in the current implementation and add the setting to limit the number of threads afterward so we can start adding multi threaded code to LLDB. What do you think? http://reviews.llvm.org/D13727 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
