[Lldb-commits] [PATCH] D133129: [lldb] Add boilerplate for debugger interrupts

Fri Sep 9 16:37:54 PDT 2022

jingham added a comment.

In D133129#3780028 <https://reviews.llvm.org/D133129#3780028>, @labath wrote:

> In D133129#3778125 <https://reviews.llvm.org/D133129#3778125>, @jingham wrote:
>
>> To be clear, I'm not trying to implement a preemptive interrupt using these callbacks.  There are so many places where lldb is doing work that you really can't interrupt - e.g. we can't drop symbol parsing and then pick it up again later - that that doesn't really even make sense.
>>
>> I started out with the goal of extending the current InterruptCommand/WasInterrupted style of voluntary interruption to more places in lldb.  A voluntary "I'm doing something in a loop that can be interrupted, so I'll check for interruption at the top of the loop" mechanism seems like the best fit for lldb, so that structure makes sense.  But we only check for interruption a few place in the "target modules" commands.  It would be useful to have other places check - e.g. if you did a `bt` and there were 40000 frames and you don't want to wait for us to print them all out...  So I was going to look into adding more interrupt checks.
>>
>> But then it seemed a shame that setting this interrupt only works when you are running command line commands, there's no reason this can't work for SB API calls as well, then UI's could also allow this sort of interruption.  If the UI code is doing something in a loop, then it's up to the UI code to handle interrupting that operation.
>
> I agree with all that.
>
>> So all I'm trying to do is set the interrupt flag for use while the currently executing SB API is in flight, then turning it off when that call exits.
>
> The problem is that, even with a single SB call, it's very hard to tell the difference between "I am doing X" vs. "I am about to do X" vs. "I have just completed X (but haven't told anyone about it)". And I don't see a way to do that reliably through any kind of automatic API boundary tracking.

I didn't see it as our job to make this distinction.  If an IDE is about to do X or is just done with X and the user hits the IDE's pause button, then it's up to the IDE to pause whatever it was doing before and after SB API calls.  We're not going to be able to interrupt anything that goes on between SB API calls anyway, so I thought it would be easier for UI's to reason about if all we did was interrupt in the current in-flight API call, which we should be able to use boundary tracking for.

>> The debugger is the one setting the interrupt flag, so we always know who is sending the interrupt.  The tricky bit is how to turn off the "WasInterrupted" flag after the API that was in flight when the flag was set finishes.
>
> Maybe the solution is to not (automatically) turn off the flag -- but put it in the hands of the user instead? If the interrupt flag was sticky (with explicit SetInterrupt/ClearInterrupt actions), then one can handle all of the scenarios above fairly easily.
> It doesn't matter that whether SetInterrupt is called before the blocking call or not -- the call is going to be interrupted anyway. And one can explicitly clear the interrupt flag after the blocking call returns (either successfully or because it was interrupted).

That's an interesting thought.  If we did that we'd have to separate the command line interrupt flags from the SB API ones w.r.t. setting/unsetting: a sticky flag is not the behavior you want for commands, but then check both in WasInterrupted.  I can't see a reason why we'd need to distinguish the two sources of interrupt at the point where we go to check.  We'd also have to never set the flag ourselves, having UI's have to spam turning this off would be super annoying, so this would have to be strictly controlled from outside lldb.  But that should be okay, if we want this behavior in the driver we can implement it outside the lldb library in the driver.   That just leaves me with the problem (even more acute with a sticky flag) of not interrupting API calls for the Debugger that didn't issue the interrupt.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133129/new/

https://reviews.llvm.org/D133129