That still doesn't address what I'm getting at -- it doesn't give a semantically meaningful name to the goroutines, in stack traces, source code, or in code visualization tools such as graphviz diagrams.
What does that goroutine actually *do*? Is it a worker for some specific purpose, does it read from stdin and forward to a pty/socket, does it wait for data on some channel, does it sleep until a particular event occurs and then reboot the box ... ? 'EnclosingFunc$1', 'EnclosingFunc$2' aren't very useful names for documentation and the current Go syntax allows no specification of this by naming the goroutine itself, short of moving it completely out of the scope of the enclosing named function, and losing the benefits of a closure. I guess what I'm getting at is that goroutines can't be named for what they *mean* or *do*. Comments can of course explain this within the source code, but I think there would be a concrete benefit to defining a convention for comment-tagging goroutines, in provide this foothold for external documentation tools; or, perhaps even better, a way to actually name goroutines like how GCC allows named, nested functions. This could even improve the readability of stack traces could it not? I've already devised a 'comment above each goroutine' hack, plus a post-processing tool (basically a sed script) to massage the output of the graphviz 'dot' data, where I place info above each goroutine so it can be renamed in the output diagram. That addresses the naming issue within graphviz diagrams for me, for now. On Sun, 25 Nov 2018 at 15:28, Dan Kortschak <dan.kortsc...@adelaide.edu.au> wrote: > That package doesn't introspect on running code, so a goroutine name is > not necessary. go-callvis could label the anonymous functions by their > filepath:line number or something else. > > On Sun, 2018-11-25 at 15:12 -0800, Russtopia wrote: > > I recently tried out a go tool for outputting code structure > > visualization > > using graphviz -- https://github.com/TrueFurby/go-callvis > > > > I found that goroutines are just labelled <enclosing function>$1 or > > similar > > by go-callvis. I could of course be wrong, but my thinking is that > > this is > > not really a shortcoming of graphviz, but rather a lack of support > > for > > naming goroutines within the language itself as goroutines are also > > 'unnamed' in this sense within stack traces. It would aid in > > understanding > > the purpose of goroutines within a structure diagram if goroutines > > could be > > named somehow. > > > > I was hoping there was a way within Go to give goroutines meaningful > > names > > in such a way that graphviz-like tools could pick up on it and make > > meaningful annotations. > > > > The runtime would, I suppose, also have to suffix a goroutine ID to a > > goroutine's name, since calling a function that contained goroutines > > repeatedly would result in multiple instances of each goroutine. > > > > > > On Fri, 23 Nov 2018 at 22:36, <alex.besogo...@gmail.com> wrote: > > > > > > > > Debugging. For example, if I have a deadlocked request I might want > > > to > > > attach with a debugger and find where exactly it's stuck. > > > > > > Right now this is complicated, you have to examine stacks of all > > > goroutines to find the correct one. > > > > > > On Friday, November 23, 2018 at 9:24:42 PM UTC-8, Andrei Avram > > > wrote: > > > > > > > > > > > > What's the need for 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 golang-nuts+unsubscr...@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-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
