A way around that might be to use the name of the variable that holds the anonymous function, defaulting to func#n when it's a func literal. This should be able to be gleaned from the analysis.
On Sun, 2018-11-25 at 16:04 -0800, Russtopia wrote: > 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.kortschak@adelaide.e > du.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. > > > > -- CRICOS provider code 00123M -- 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.
