> On Jul 27, 2016, at 10:08 AM, Pavel Labath <lab...@google.com> wrote: > > On 27 July 2016 at 17:41, Jim Ingham <jing...@apple.com> wrote: >> If you go to halt a thread whose private state is running, and by the time >> you get to halting it the private state has gone from running to stopped >> then the code doing the halt will declare victory, since that's what it was >> trying to do. If it was still running, then it will have to interrupt. I >> don't see how this will be flakey. >> > > This case is fine. The tricky part is the opposite: > - we check the private state, see that it is stopped and decide that > we have nothing to do > - meanwhile, the private state flips back to running (e.g. because it > was just temporarily stopped while it was stepping over a breakpoint) > - RunThreadPlan carries on running oblivious to the fact that someone > tried to interrupt it > - process does not stop
Yes, I see. This change always checks public state running, so all the flips from run to stopped in the private state thread will have no effect on all the modes of running except expression evaluation. The change as is is better than what was there before, even though it doesn't handle this case. This check will fix the case where you have an expression that stalls and you go to kill the process (you have to be using a UI to do this, since otherwise you'd have to interrupt the expression to type "kill".) Before this change, Destroy would do nothing in this case. That's much more common than happening to be in the I have other things on my plate right now, but I filed: https://llvm.org/bugs/show_bug.cgi?id=28742 to remind myself to go back and make this better. Jim _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits