<div dir="ltr">Hey all,<div><br></div><div>I noticed on the local debugging side that the following events result in all threads stopping (at least as a private stop, and at least on local Linux debugging):</div><div><ul><li>
new thread creation</li><li>breakpoint/trace hit</li><li>watchpoint hit</li><li>crash</li></ul><div>Regarding a remote stub, (ab) should I assume that the client will request all threads stop when those events occur and are reported by a stop notification, such that the stub can ignore those details, or (b)  should the stub perform an all-stop in all of those cases before reporting the triggering event(s)?</div>
<div><br></div><div>e.g.</div><div>1. New thread is detected on stub.</div><div><br></div><div>At this point - do I just keep the thread stopped and report a stop result for the thread, or do I make sure all threads are stopped, then report the stop?</div>
<div><br></div><div>2. Breakpoint hit.</div><div><br></div><div>At this point - do I just report the breakpoint being hit with a stop notification, or do I stop all threads first and then report the breakpoint being hit on the thread?</div>
<div><br></div><div>Similarly for watchpoints, etc.</div><div><br></div><div>Thanks!  I'm hopeful the answer is "the client handles the details of all other thread behavior, just report what you see on the stub."</div>
<div><br></div><div>I'm walking through all the llgs signal handling code and trying to make sure it's all doing the proper actions, but comparison to the local debugging case is not always helpful since local debugging is essentially the same as client+stub in the remote case, and the line of what is a client responsibility vs. a stub responsibility is less clear.</div>
<div><br></div><div>Much appreciated!<br>-Todd</div><div><br></div>
</div></div>