With ProcessWindows, most of the OS notifications from the process (breakpoints, thread creation, etc) are going to come in via a background thread.  <div><br></div><div>The way I see this being handled in Virgile's implementation of ProcessWindows which I'm working on merging up is as follows:</div><div><br></div><div>1) When events happen, put their parameters into some struct and put it in a queue</div><div>2) Stop the process, which triggers a RefreshStateAfterStop call to the process plugin on the main thread, and then block the debugger thread.</div><div>3) In RefreshStateAfterStop, process the message that was put onto the queue, update the thread list, etc, and then signal the debugger thread to wake up.</div><div><br></div><div>Is there a technical reason why we have to do this with message passing and doing all the work in RefreshStateAfterStop?</div><div><br></div><div>For example, suppose we get a create thread notification.  Shouldn't it just be possible to acquire the thread list's mutex and stick the new thread onto the end of it without the message passing and all that?  Why do all threads have to stop just because one new thread was created?</div><div><br></div><div>Is this necessary for some reason common to all plugins and platforms, or is it something specific to the implementation here, and there's no underlying fundamental reason why it shouldn't work with the right synchronization.</div>