Sure. I just found it a very interesting 'corner' of the language I have
run up against.
However, I do have what I think is an ingenious solution which
unfortunately cannot fit in the margin of this email :). It's actually
working rather well for my purposes, and I've proposed it already to the
author of go-callvis. We'll see where it goes.
I think given the Go philosophy of keeping the language itself simple, a
convention for annotating goroutines (and defer blocks which also show up
in graphvis in the same manner) via comments might be best. A
post-processing tool to catch these comments and fix up the graphviz .dot
output is already showing promise in achieving what I am after.
-Russ
On Sun, 25 Nov 2018 at 20:13, Michael Jones <michael.jo...@gmail.com> wrote:
> just saying the we could make it so. the full name (for a func local var)
> would be funcName_varName_instanceNumber in some formatting.
>
> i think you're up against a "go attitude" decision here but it could help
> support the tooling spirit...would be nice to see the list if these at exit
> to quickly spot leaking
>
> On Sun, Nov 25, 2018 at 8:05 PM Russtopia <rma...@gmail.com> wrote:
>
>> 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.
>>
>
>
> --
>
> *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>*
>
--
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.
