The following situation was occuring in TestAttachResume:
- we did a "continue" from a breakpoint (which involves a private start-stop to step over the breakpoint)
- after receiving the stop-reply from the step-over, we issue a "detach" (which requires a process interrupt)
- at this moment, the public state is "running", private state is "about-to-be-stopped" (the stopped event was broadcast, but it was not received yet)
- StopForDestroyOrDetach (public thread) notes the public state is running, sends an interrupt request to the private thread
- private thread gets the eBroadcastBitInterrupt (before the eStateStopped message), and asks the process plugin to stop (via Halt())
- process plugin says it has nothing to do as the process is already stopped
- private thread shrugs and carries on. receives the stop event, restores the breakpoint and resumes the process.
- after a while, the public thread times out and says it failed to stop the process
This patch does the following:
- splits Halt() into two functions, private and public, their usage depends on the context
- public Halt(): sends eBroadcastBitInterrupt to the private thread and waits for the Stop event
- HaltPrivate(): asks the plugin to stop and makes a note that the halt was requested. When the next stop event comes it sets the interrupt flag on it.
- removes HijackPrivateProcessEvents(), as the only user (old Halt()) has gone away
- removes the m_currently_handling_event hack, as the new Halt() does not need it
- adds a use_run_lock parameter to public Halt() and WaitForProcessToStop(). This was needed because RunThreadPlan uses Halt() while holding the run lock and we don't want Halt() to take it away from him.