FAQ
*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


--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Brad Fitzpatrick at Aug 19, 2014 at 9:31 pm
    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".


    On Tue, Aug 19, 2014 at 1:02 PM, wrote:

    *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


    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Rob Pike at Aug 19, 2014 at 10:05 pm
    What Brad said.

    -rob

    On Tue, Aug 19, 2014 at 2:31 PM, Brad Fitzpatrick wrote:
    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".


    On Tue, Aug 19, 2014 at 1:02 PM, wrote:

    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


    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Aug 19, 2014 at 10:27 pm
    What Rob said.
    On Wed, Aug 20, 2014 at 8:05 AM, Rob Pike wrote:
    What Brad said.

    -rob

    On Tue, Aug 19, 2014 at 2:31 PM, Brad Fitzpatrick wrote:
    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".


    On Tue, Aug 19, 2014 at 1:02 PM, wrote:

    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


    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Carlos Castillo at Aug 19, 2014 at 10:08 pm
    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*.
    On Tuesday, August 19, 2014 2:31:07 PM UTC-7, Brad Fitzpatrick wrote:

    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".



    On Tue, Aug 19, 2014 at 1:02 PM, <stuart...@gmail.com <javascript:>>
    wrote:
    *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


    --
    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 <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Stuart Carnie at Aug 19, 2014 at 10:44 pm
    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:

    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".



    On Tue, Aug 19, 2014 at 1:02 PM, <stuart...@gmail.com <javascript:>>
    wrote:
    *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


    --
    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 <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Stuart Carnie at Aug 19, 2014 at 11:56 pm

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


    On Tuesday, August 19, 2014, Stuart Carnie <stuart...@gmail.com
    <javascript:>> 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

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

    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".


    On Tue, Aug 19, 2014 at 1:02 PM, wrote:

    *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


    --
    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.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

    --
    Carlos Castillo
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dan Kortschak at Aug 20, 2014 at 12:29 am
    The abuse is already available. If you really want it you can map to
    names.

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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Niklas Schnelle at Aug 20, 2014 at 1:43 pm
    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
    On Wednesday, August 20, 2014 2:29:04 AM UTC+2, Dan Kortschak wrote:

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

    http://play.golang.org/p/biXhGbxQ3C
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Stuart Carnie at Aug 20, 2014 at 2:22 pm
    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
    On Wednesday, August 20, 2014 6:43:00 AM UTC-7, Niklas Schnelle wrote:

    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
    On Wednesday, August 20, 2014 2:29:04 AM UTC+2, Dan Kortschak wrote:

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

    http://play.golang.org/p/biXhGbxQ3C
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedAug 19, '14 at 9:23p
activeAug 20, '14 at 2:22p
posts10
users7
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase