dellve: 0.12.1
go:1.7.4
os: macos sierra 10.12.3
background: when i debugging a websocket program, the goroutine who should pong the server's ping request in backgrond but it's pause automatically when breakpoint hit in other functionality, so the websocket connection will close after timeout. So i want that goroutine keep running.
example:
func main(){
go handleWS()
print("abc") //<- breakpoint set here
}
func handleWS(){
//handle websocket ping pong
.....
}
It's possible to implement this but very complicated.
@aarzilli Thanks for your reply, it's really helpful for us when debugging web applications
+1 to this.
Now I understand why I see all the goroutines with state "PAUSED ON BREAKPOINT" in VSCODE.
I believe that letting all other threads/goroutines run until they reach a breakpoint is pretty common in debuggers, right? Shouldn't delve just pause any goroutine when it hits a breakpoint?
And what should happen when a second breakpoint is hit in the background?
@au-phiware when a breakpoint is hit in the background, then that goroutine is paused on that breakpoint, that's what happens while debugging java, for example.
To make things clear: say we have 3 goroutines, 2 share the same code (let's call codeA). When you put a breakpoint in codeA and that breakpoint is hit by these 2 goroutines, then only these 2 goroutines should pause at the breakpoint, the other one should be left running. Also goroutines sharing same code (and hence the same breakpoint) doesn't necessarily mean that they will both stop at the same point.
I'm not trying to say it's an easy feature to implement, though I think it's the desired behavior and also probably many other debuggers work that way.
Most helpful comment
@au-phiware when a breakpoint is hit in the background, then that goroutine is paused on that breakpoint, that's what happens while debugging java, for example.
To make things clear: say we have 3 goroutines, 2 share the same code (let's call
codeA). When you put a breakpoint incodeAand that breakpoint is hit by these 2 goroutines, then only these 2 goroutines should pause at the breakpoint, the other one should be left running. Also goroutines sharing same code (and hence the same breakpoint) doesn't necessarily mean that they will both stop at the same point.I'm not trying to say it's an easy feature to implement, though I think it's the desired behavior and also probably many other debuggers work that way.