How to find goroutines during debugging - aka goroutine labeling

[Florin Pățan]

Hello gophers,

There have been a number of posts in the past discussing how to handle large number of goroutines in applications when it comes to debugging them.

Since Delve, the Go debugger, and GoLand, the Go IDE from JetBrains, recently got the ability to handle these, I thought I'd share this quick post on how to use this feature and make your life easier.

You can find it here: https://blog.jetbrains.com/go/2020/03/03/how-to-find-goroutines-during-debugging/

Looking forward for your thoughts on this.

[Robert Engels]

This is awesome and sad. The marketplace is now steering Go - which was bound to happen. You can't ignore the needs of the marketplace and expect it to standstill. This is a clear feature that the Go team (and community) should of taken more seriously and a better solution would of been delivered. But at least it's solved (at the expense of performance).

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/47087123-a14a-4139-af84-7208a05a5ca1%40googlegroups.com.

[Florin Pățan]

I think the current solution is a perfectly reasonable solution.

As I explained in the article, you can have 0 performance impact when used in production environments, because you can disable this feature.

And when used in debugging environments, this has a minimal performance impact.

For more details see: https://github.com/dlsniper/debugger/#performance which provides a library which makes this feature opt-in, at compile time.

What do you think could be done better to support this feature?

On Wednesday, March 4, 2020 at 12:38:54 AM UTC+2, Robert Engels wrote:

This is awesome and sad. The marketplace is now steering Go - which was bound to happen. You can't ignore the needs of the marketplace and expect it to standstill. This is a clear feature that the Go team (and community) should of taken more seriously and a better solution would of been delivered. But at least it's solved (at the expense of performance).

-----Original Message-----
From: Florin Pățan
Sent: Mar 3, 2020 9:11 AM
To: golang-nuts
Subject: [go-nuts] How to find goroutines during debugging - aka goroutine labeling

Hello gophers,

There have been a number of posts in the past discussing how to handle large number of goroutines in applications when it comes to debugging them.

Since Delve, the Go debugger, and GoLand, the Go IDE from JetBrains, recently got the ability to handle these, I thought I'd share this quick post on how to use this feature and make your life easier.

You can find it here: https://blog.jetbrains.com/go/2020/03/03/how-to-find-goroutines-during-debugging/

Looking forward for your thoughts on this.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golan...@googlegroups.com.

[Jesper Louis Andersen]

On Wed, Mar 4, 2020 at 7:24 AM Florin Pățan <flori...@gmail.com> wrote:

I think the current solution is a perfectly reasonable solution.

As I explained in the article, you can have 0 performance impact when used in production environments, because you can disable this feature.

My experience is that a little performance impact is a small price to pay for having better instrumentation in a system. Often, it allows you to observe the behavior of the running system and this leads to optimizations in the system long before they become a problem in production environments. If we have a place where we should use all the power a modern CPU gives us, I think this is a good place. Knowledge of a programs execution profile is often extremely valuable in the long run. The key reason being that once you have real users in the system, they start using your applications in ways you never imagined they would. And thus, they often redefine what is a hot code path inside the code base, requiring optimization. Also, you will have outlier users who puts pressure on your system. But those outliers today are the common user tomorrow, so optimizing for them is also beneficial. You can skip this, in the name of efficiency, but chances are you will be in peril as your are working blindly on assumptions about the programs execution behavior.

As for the solution, I think it looks fine as well. Process tagging is something I've used in many systems with massive concurrency, as the knowledge is invaluable in post-mortem situations. Observability is important[0].

[0] The by far best definition of Observability I've seen is due to Charity Majors, who lifted the term straight out of Control Theory: https://en.wikipedia.org/wiki/Observability It is one of those highly formal definitions which informal spirit applies quite well to software.

[Robert Engels]

This is what I was referring to by performance. I think it needs to be "always on", and should be included in stack-traces - but we need exceptions first :)

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGrdgiU9bRnemqP4QSOu2dnANMy%3DxWC4-JbivcBupPYSoi8U4g%40mail.gmail.com.