tfiala added a comment. In http://reviews.llvm.org/D13727#268096, @clayborg wrote:
> In http://reviews.llvm.org/D13727#268091, @tberghammer wrote: > > > I agree that parking the threads in the kernel should be very cheap (I am > > not sure about Windows) but on high end multi core machines having 40+ > > threads around just to wait for work is a bit strange for me too and it > > definitely makes debugging of LLDB more difficult. > > > Ok, maybe we can pick a larger timeout then like say 2 seconds? Yeah I definitely like the idea of retiring the threads when they're not getting used for some length of time (and configurable but in the seconds range sounds reasonable as a default). When we're on OS X machines, they tend to be capped out at 8 cores (although the Mac Pros can get up to 24 logical cores). It is ugly on systems with higher core counts to leave threads around. (As an aside, it might be interesting to have the debugger keep track of last time a thread run and hide threads that have been inactive if we know about well-known "park" locations, but not for the general case --- IDEs could conceivably make use of that to hide dormant threads. Although I suppose the IDE could do that entirely without lldb tagging a thread state as dormant). > > In the near future I expect that we will use the TaskPool only for very > > heavy computations while we filling up our internal caches (such as debug > > info parsing or symtab parsing) and then don't use it for anything later. > > > I want to used it in many ModuleList functions like: > > ModuleList::FindFunctionSymbols() > ModuleList::FindFunctions() > ModuleList::FindCompileUnits() > ModuleList::FindGlobalVariables() > ModuleList::FindSymbolsWithNameAndType() > ModuleList::FindSymbolsMatchingRegExAndType() > > and many more. http://reviews.llvm.org/D13727 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
