Perhaps I misunderstand what you suggest, but I tried
func A() {
...
descriptivelyNamedGoroutine := func() {
...
}
...
descriptivelyNamedGoroutine()
...
Alas, the 'dot' tool used by go-callvis doesn't seem to obtain any
additional info from this. The resulting diagram still just labels the
goroutine A$1.
Perhaps a limitation of go-callvis itself; I've mailed the author with this
issue to see what he/she thinks about it.
On Sun, 25 Nov 2018 at 16:36, Dan Kortschak <dan.kortsc...@adelaide.edu.au>
wrote:
> 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.
