[lldb-dev] Parallelizing loading of shared libraries

[Scott Smith via lldb-dev]

On Mon, May 1, 2017 at 2:42 PM, Pavel Labath <labath at google.com> wrote:

> Besides, hardcoding the nesting logic into "add" is kinda wrong.
> Adding a task is not the problematic operation, waiting for the result
> of one is. Granted, generally these happen on the same thread, but
> they don't have to be -- you can write a continuation-style
> computation, where you do a bit of work, and then enqueue a task to do
> the rest. This would create an infinite pool depth here.
>

True, but that doesn't seem to be the style of code here.  If it were you
wouldn't need multiple pools, since you'd just wait for the callback that
your work was done.


>
> Btw, are we sure it's not possible to solve this with just one thread
> pool. What would happen if we changed the implementation of "wait" so
> that if the target task is not scheduled yet, we just go ahead an
> compute it on our thread? I haven't thought through all the details,
> but is sounds like this could actually give better performance in some
> scenarios...
>

My initial reaction was "that wouldn't work, what if you ran another posix
dl load?"  But then I suppose *it* would run more work, and eventually
you'd run a leaf task and finish something.

You'd have to make sure your work could be run regardless of what mutexes
the caller already had (since you may be running work for another
subsystem), but that's probably not too onerous, esp given how many
recursive mutexes lldb uses..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170501/d146ccf5/attachment.html>