labath added a comment. 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. > 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). CHANGES SINCE LAST ACTION https://reviews.llvm.org/D133129/new/ https://reviews.llvm.org/D133129 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
