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 <ztur...@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@lists.llvm.org> wrote: > >> On Mon, May 1, 2017 at 2:42 PM, Pavel Labath <lab...@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@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
