[lldb-dev] Parallelizing loading of shared libraries

[Scott Smith via lldb-dev]

IMO we should start with proving a better version in the lldb codebase, and
then work on pushing it upstream.  I have found much more resistance
getting changes in to llvm than lldb, and for good reason - more projects
depend on llvm than lldb.


On Mon, May 1, 2017 at 9:48 PM, Zachary Turner <zturner at google.com> wrote:

> I would still very much prefer we see if there is a way we can adapt
> LLVM's ThreadPool class to be suitable for our needs.  Unless some
> fundamental aspect of its design results in unacceptable performance for
> our needs, I think we should just use it and not re-invent another one.  If
> there are improvements to be made, let's make them there instead of in LLDB
> so that other LLVM users can benefit.
>
> On Mon, May 1, 2017 at 2:58 PM Scott Smith via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
>
>> 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..
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170501/3de6f10c/attachment-0001.html>