jingham added a comment. 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. 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 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. That requires as a first step the ability to mark the "top level SB API" boundaries, and that's what Jonas was showing me how to do here. With these callbacks, some parts of this tracking will be straightforward, like by tracking enter and leave I can drop the interrupt flag immediately if there are no API's currently running. And if there were only one API in flight, turning the flag off at the right time is straight forward. But you are right, there are tricky bits around handling two SB API's in flight on different threads. If they are for the same debugger, we probably do want to interrupt both. However, you don't want a short operation on thread A to turn off the interrupt flag before a long operation on thread B gets a chance to check it. So we'll probably want a counter and not just a flag. However, it doesn't make sense for one Debugger's interrupt to interrupt the actions of another, so somehow we're going to have segregate API calls based on debugger, which I don't know how to do yet. Anyway, this patch was mainly Jonas showing me how to get hook points for the enter and leave point for the top-level SB API calls so I could start to play with how to do this. TTTT I thought it would be more complex than this, and so it seemed worthwhile to add the general facility downstream. This is sufficiently straightforward, however, that I am fine with keeping it locally while I play with it. This isn't really a new feature, it's just extending lldb's current voluntary interrupt mechanism to work that initiates from the SB API as well as to the command line. But once I get a better idea of how to do this, depending on how tricky it ends up being I'll either put up a patch or an RFC. 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
