jasonmolenda wrote: For what it's worth, this thread pool for parallel processing has been used in another part of lldb - it's used on ELF systems when processing DWARF, when we need to scan the debug info in the individual .o files iirc. So we've had some living-on time with the thread pool approach there, not used on Darwin, but used on other targets.
I was chatting with Jim Ingham and he was a little bummed that we're looking at doing this in a single DynamicLoader plugin, instead of having the DynamicLoader plugin create a list of ModuleSpec's and having a central method in ModuleList or something, create Modules for each of them via a thread pool, and then the DynamicLoader plugin would set the section load addresses in the Target, run any scripting resources (python in .dSYMs), call ModulesDidLoad etc. I don't think you should have to do the more generalized approach in this PR, but a scheme where other targets like Linux can benefit from the same approach would be interesting, without duplicating the thread pool code in their plugins. More like something for future work. I still haven't looked at the specific code changes yet :) I've been trying to exercise this approach in a few different environments and it seems like a benefit in nearly every case, to varying degrees. (the only case where it didn't benefit was when lldb had no binaries locally, and had to read them all over the gdb remote serial protocol. In that case all threads were blocked on the communication over the USB cable, reading all the libraries. The multithreaded approach didn't make this slower, and didn't seem to cause a problem, those were the main things I was looking for.) https://github.com/llvm/llvm-project/pull/110439 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
