JDevlieghere wrote:

> Can we not just use a `Progress` object instead of installing a callback? 
> Seems like a very specific use case to install a callback for in our public 
> API. Do we create `Progress` objects for each background download? If we 
> don't, should we? Then this would show up in the command line like 
> "Downloading symbols for ..." and it might communicate to the user what is 
> happening better than "Waiting for background tasks to complete...".

We do emit progress events for all the downloads, but there's two reasons this 
doesn't work as you expect:

1. Currently, the default event handler ignores events that are shadowed. So if 
I kick off 4 downloads at the same time, we'll show the progress event for the 
first one only. The reason for this how we use ANSI escape codes to redraw the 
current line. I actually have something in the works to change that, but even 
if I can fix that, there's a second issue:

2. The thread pool is global and by the time we terminate, the debugger has 
already been destroyed, which includes it event handler thread and even its 
output stream. 

> What would happen if we could add an internal API that would cancel all 
> background downloads of symbols?

That's what I described at the bottom of the description. You could come up 
with an ad-hoc solution for symbol downloads, but if we want to lean on the 
thread pool more, we'll see the same issue in other places too. If we want to 
go that route I think we should do it at the ThreadPool level and make all 
tasks (cooperatively) interruptible.  

> I am not sure I like installing a specific callback for thread pool issues. 
> What if a thread gets deadlocked waiting for data and it never completes the 
> download?

That's already a risk. The 
[ThreadPool](https://llvm.org/doxygen/classllvm_1_1ThreadPool.html) explicitly 
provides no guarantees around deadlocking. 

https://github.com/llvm/llvm-project/pull/82799
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to