Bug ID 28742
Summary Make Process::StopForDestroyOrDetach handle interrupting RunThreadPlan more robustly
Component All Bugs
See the discussion in commit r276795. As Pavel said there: 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 So the Process has to have a way to flag that RunThreadPlan should interrupt it's work. This is a little tricky because, if you need to send a signal to interrupt but the process stops with the signal pending, you will also need to pull off that signal or when you detach it will go to the process and likely kill it.