<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">A worker thread would call DynamicLoader::LoadModuleAtAddress.  This in turn eventually calls SymbolFileDWARF::Index, which uses TaskRunners to<br>1. extracts dies for each DWARF compile unit in a separate thread<br></div><div class="gmail_quote">2. parse/unmangle/etc all the symbols<br><br></div><div class="gmail_quote">The code distance from DynamicLoader to SymbolFileDWARF is enough that disallowing LoadModuleAtAddress to block seems to be a nonstarter.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br>On Wed, Apr 26, 2017 at 4:23 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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?<br><div class="gmail_quote"><div><div class="gmail-h5"><div dir="ltr">On Wed, Apr 26, 2017 at 4:12 PM Scott Smith via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5"><div dir="ltr"><div><div><div><div><div><div><div>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.  That's a lot of threads :-)<br><br></div>The problem is loading a shared library can cause downstream parallelization through TaskPool.  I can't then also have the loading of a shared library itself go through TaskPool, as that could cause a deadlock - if all the worker threads are waiting on work that TaskPool needs to run on a worker thread.... then nothing will happen.<br><br></div>Three possible solutions:<br><br></div>1. Remove the notion of a single global TaskPool, but instead have a static pool at each callsite that wants it.  That way multiple paths into the same code would share the same pool, but different places in the code would have their own pool.<br><br></div>2. Change the wait code for TaskRunner to note whether it is already on a TaskPool thread, and if so, spawn another one.  However, I don't think that fully solves the issue of having too many threads loading shared libraries, as there is no guarantee the new worker would work on the "deepest" work.  I suppose each task would be annotated with depth, and the work could be sorted in TaskPool though...<br><br></div>3. Leave a separate thread per shared library.<br><br></div>Thoughts?<br><br></div></div></div></div>
______________________________<wbr>_________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/lldb-dev</a><br>
</blockquote></div>
</blockquote></div><br></div></div>