Please note, that the FAQ doesn't really apply to my proposal. If you can set a name but not read it (without resorting to stack trace parsing or CGO) then you can't use it to create implicit thread-local contexts.
On Sunday, November 25, 2018 at 4:17:28 PM UTC-8, Bruno Albuquerque wrote: > > Terra os a FAQ Abbott this, if I understand what you want correctly: > https://golang.org/doc/faq#no_goroutine_id > > On Sun, Nov 25, 2018, 4:04 PM Russtopia <rma...@gmail.com <javascript:> > 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.ko...@adelaide.edu.au >> <javascript:>> 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.be...@gmail.com <javascript:>> >>> 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...@googlegroups.com <javascript:>. >>> > > 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...@googlegroups.com <javascript:>. >> 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.
