debugger was able to suspend thread only when code was reaching software breakpoint -- hook callback. so hitting "pause" in debugger in general wasn't doing anything if there was no hook instrumented java code running (e.g. threads are waiting on lock/sleep or running native message loop).
Also debugger wasn't picking JDWP thread statuses like sleeping/monitor etc.
thread status
thread status was not propagated from VM (hooks) to JDWP and was solved by extending the protocol.
changes to suspend threads
interrupt any random thread is possible by sending a signal to it. There is already two signals dedicated to RoboVM and introducing another one would be wastefully.
Lucky for us one signal was used to capture thread stack trace. Last ones also good to have when you suspend the thread. So it was extended to provide a callback to hooks infrastructure and if thread was pending for suspend -- suspend loop was running there. Debugger code was updated to support these changes in debugger-hooks protocol.
background
debugger was able to suspend thread only when code was reaching software breakpoint -- hook callback. so hitting "pause" in debugger in general wasn't doing anything if there was no hook instrumented java code running (e.g. threads are waiting on lock/sleep or running native message loop). Also debugger wasn't picking JDWP thread statuses like sleeping/monitor etc.
thread status
thread status was not propagated from VM (hooks) to JDWP and was solved by extending the protocol.
changes to suspend threads
interrupt any random thread is possible by sending a signal to it. There is already two signals dedicated to RoboVM and introducing another one would be wastefully. Lucky for us one signal was used to capture thread stack trace. Last ones also good to have when you suspend the thread. So it was extended to provide a callback to hooks infrastructure and if thread was pending for suspend -- suspend loop was running there. Debugger code was updated to support these changes in debugger-hooks protocol.