[lldb-dev] Running other threads while stepping

[jingham at apple.com]

On Sep 6, 2013, at 8:24 AM, Ed Maste <emaste at freebsd.org> wrote:

> Jim - thanks for this comprehensive and detailed post.
> 
> On 5 September 2013 22:28,  <jingham at apple.com> wrote:
>> ...
>> The other option would be to do some timing kind of heuristic, where we let only one thread run with a timeout, and if it doesn't return after that timeout we interrupt it resume it with all threads running.  That might be worth trying, but you'd have to put in place a mechanism for ThreadPlans to register a timeout and a callback on timeout that could adjust and restart the process, and that isn't in place yet.  Not sure this would appear any more arbitrary than what we do now, however, though it might allow more code to run on only a single thread.
> 
> Yes, in my opinion that would seem even more arbitrary which is what
> I'd like to avoid (and not the actual behaviour itself).  Do you think
> it'd be reasonable to provide a user-facing message when we run other
> threads during stepping?

I'm not sure about emitting a message, people generally don't like being told something they don't really understand and can't do anything about.  And adding output to the console window should be done judiciously anyway, since that makes it harder to read the output you really care about.

I do want to add some command that will inspect the current thread plans, so you could see how they are stacked and cancel ones you don't care about anymore.  For instance, if you do:

step over -> hit a breakpoint below on the stack
step over -> hit another breakpoint

etc.  Then if you continue, you'll finish the latest step over (unless you hit another breakpoint in the process...)  Then continue again will complete the second step over.  This is often quite convenient, but sometimes you just want to forget about the step-over's and continue running.  This would provide a way to do that.  Perhaps that would be a good place to insert some info about how the plans will run the threads.

Jim