After a dealing with a bunch of microoptimizations, I'm back to
parallelizing loading of shared modules. My naive approach was to just
create a new thread per shared library. I have a feeling some users may
not like that; I think I read an email from someone who has thousands of
shared libraries.
Under what conditions would a worker thread spawn additional work to be run
in parallel and then wait for it, as opposed to just doing it serially? Is
it feasible to just require tasks to be non blocking?
On Wed, Apr 26, 2017 at 4:12 PM Scott Smith via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
>
A worker thread would call DynamicLoader::LoadModuleAtAddress. This in
turn eventually calls SymbolFileDWARF::Index, which uses TaskRunners to
1. extracts dies for each DWARF compile unit in a separate thread
2. parse/unmangle/etc all the symbols
The code distance from DynamicLoader to SymbolFile
We started out with the philosophy that lldb wouldn't touch any more
information in a shared library than we actually needed. So when a library
gets loaded we might need to read in and resolve its section list, but we won't
read in any symbols if we don't need to look at them. The idea was th
(+LLDB-Dev) most of the LLDB developers hang out there more than on LLVM-Dev.
> On Apr 26, 2017, at 12:26 PM, Demi Marie Obenour via llvm-dev
> wrote:
>
> LLDB currently uses a client-server architecture. That appears fine,
> but runs into an annoying security problem: other users on the same
