[Lldb-commits] [PATCH] D150805: Rate limit progress reporting

saugustine added a comment. Any more thoughts on this from the reviewers? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D150805/new/ https://reviews.llvm.org/D150805 ___ lldb-commits mailing list lldb-com

[Lldb-commits] [PATCH] D150805: Rate limit progress reporting

JDevlieghere added a comment. My suggestion was to add rate limiting support to the listener so that all events could benefit from this. The current patch seems unnecessary ad-hoc: it's limited to (1) progress events and (2) the default event handler. I expects that lldb-vscode plugin users suf

[Lldb-commits] [PATCH] D150805: Rate limit progress reporting

saugustine abandoned this revision. saugustine added a comment. I'll let someone with a better understanding of the proper implementation take it from here. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D150805/new/ https://reviews.llvm.org/D150805

[Lldb-commits] [PATCH] D150805: Rate limit progress reporting

rupprecht added a comment. In D150805#4350849 , @JDevlieghere wrote: > I also like Jordan's rate limiting idea. In my mind that should be a property > of the broadcaster. Different tools (e.g. vscode vs the command line) could > specify different value

[Lldb-commits] [PATCH] D150805: Rate limit progress reporting

saugustine added a comment. In D150805#4397940 , @rupprecht wrote: > In D150805#4350849 , @JDevlieghere > wrote: > >> I also like Jordan's rate limiting idea. In my mind that should be a >> property of the broad

[Lldb-commits] [PATCH] D150805: Rate limit progress reporting

rupprecht added a subscriber: labath. rupprecht added a comment. The other tricky part I missed before is this bit in between pulling the event off the listener queue and deciding to show it: auto *data = ProgressEventData::GetEventDataFromEvent(event_sp.get()); if (!data) return; /

[Lldb-commits] [PATCH] D150805: Rate limit progress reporting

labath added a comment. I agree that we should have a rate limiting mechanism very close to the source, to avoid wasting work for events that aren't going to be used. This is particularly important for debug info parsing, where we have multiple threads working in parallel and taking a lock even