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.
