proposal: add APIs for naming goroutines for debugging

[stuart...@gmail.com]

Summary:

Add 2 additional APIs to the runtime package for being able to set a name for the current goroutine to enhance debugging and profiling. These are analogous to POSIX pthread_setname_np / pthread_getname_np. Tools such as Apple's lldb or Instruments show the thread names in the UI or when listing threads to make them easier to locate when debugging; these same benefits would apply to go.

/// SetGoroutineName assigns a name to the current goroutine
runtime.SetGoroutineName(string name)

/// GetGoroutineName returns the name assigned to the current goroutine
runtime.GetGoroutineName() string

goroutines do not need to be named and an empty string would be returned if not set

In the same vein as the pthread get/set name APIs, providing support for naming goroutines would improve debugging and profiling:

• the goroutine gdb command could use either <goid> OR <goname>
• the goroutines gdb command would print both goid and goname
• current stacks traces could include names of goroutines, making it easier to locate and inspect specific goroutines
  
• naming goroutines which are long-lived and typically performing background or maintenance work would prove useful
  

Implementation notes:

• Modify struct G, adding a new member, pointer to the goname (nil by default)
  
• Modify goexit0, to free goname if not nil
  
• Add new internal runtime APIs to set/get goname for current goroutine (identified by global g variable)
  
• would runtime·malloc and runtime·free be the appropriate APIs?
• Add new public runtime APIs to get/set name
  
• Extend runtime-gdb.py to support goname
• Update runtime·goroutineheader(G *gp) to include goroutine name in output if set.
  
• Would be a problem if this header structure is expected to be consistent, as we'd be adding another string to the "goroutine <goid>" line in the output

Look forward to comments and concerns.

Cheers,

Stuart

[Brad Fitzpatrick]

While useful for debugging, one major fear is that this would be used as state.  For the same reasons we don't provide goroutine-local-storage (like thread local storage), we wouldn't want people to make restrictions about which goroutine names certain things could run on.  Inevitably people would start using goroutine names as their locking rules and then we're back to the bad ol' days of thread-unsafe C libraries or ones where things can only be called "on the main thread".

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rob Pike]

What Brad said.

-rob

[Carlos Castillo]

If it were only to be used for debugging, then runtime.GetGoroutineName wouldn't be needed, as there would be no need for the goroutine to ever query it's own name. That would avoid the TLS (GLS) issue, but seems to be little different than starting "special" goroutines from specific functions. Eg:

go backgroundWorker(...)

And that shows up in stack-traces *now*.

[Dave Cheney]

What Rob said.

[Stuart Carnie]

Don't disagree and I should have added that the GetGoroutineName API is not required. I had similar concerns that it could be abused at runtime. With it excluded, are there still concerns?

Whilst it is true a stack trace would likely identify "background" goroutines, locating them within gdb would still be simplified if one could name certain goroutines. Also by enabling goroutine naming, we would have another data point when mining debug / profile data.

On Tuesday, August 19, 2014 2:31:07 PM UTC-7, Brad Fitzpatrick wrote:

[Carlos Castillo]

On Tuesday, August 19, 2014, Stuart Carnie <stuart...@gmail.com> wrote:

Don't disagree and I should have added that the GetGoroutineName API is not required. I had similar concerns that it could be abused at runtime. With it excluded, are there still concerns?

Whilst it is true a stack trace would likely identify "background" goroutines, locating them within gdb would still be simplified if one could name certain goroutines. Also by enabling goroutine naming, we would have another data point when mining debug / profile data.

You don't have access to stack-traces when debugging / profiling?

 

You received this message because you are subscribed to a topic in the Google Groups "golang-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-dev/s8qm8n_uHNY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-dev+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Carlos Castillo

[Stuart Carnie]

On Tuesday, August 19, 2014 4:36:47 PM UTC-7, Carlos Castillo wrote:

On Tuesday, August 19, 2014, Stuart Carnie <stuart...@gmail.com> wrote:

Don't disagree and I should have added that the GetGoroutineName API is not required. I had similar concerns that it could be abused at runtime. With it excluded, are there still concerns?

Whilst it is true a stack trace would likely identify "background" goroutines, locating them within gdb would still be simplified if one could name certain goroutines. Also by enabling goroutine naming, we would have another data point when mining debug / profile data.

You don't have access to stack-traces when debugging / profiling?

You do, however in gdb it would be much easier to locate a specific goroutine if it were named

 

 

To unsubscribe from this group and all its topics, send an email to golang-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Carlos Castillo

[Dan Kortschak]

The abuse is already available. If you really want it you can map to
names.

http://play.golang.org/p/biXhGbxQ3C

[Niklas Schnelle]

Couldn't the compiler add the line and file information of the go statement that launched the goroutine so it's accessible to the debugger only. This would allow seeing where a certain goroutine comes from

[Stuart Carnie]

go already has call hierarchy across goroutines (i.e. where it was launched from) within a stack trace.

That is not the purpose of this proposal. As a developer, we want to quickly identify and debug specific goroutines – therefore being able to name them would facilitate that goal. goroutines are normally assigned an incrementing integer "goid", however that is not reliable nor is it intuitive via gdb.

Cheers,

Stuart