proposal: add constant flag in logging to log the goroutine id to trace the bug

[NetWilliam]

I have understood that there are some disadvantages in getting the goroutine ID in the program. However, I also have noticed that in https://golang.org/pkg/log/#pkg-constants we have some approach to logging the file name and line no etc...

I think it would very useful in the debugging of a program if goroutine ID could be logged in a similar way.

[mvdan]

There's no such thing as a goroutine ID, so I don't see how this proposal can be accepted: https://golang.org/doc/faq#no_goroutine_id

[agnivade]

@NetWilliam is aware of the faq link. I had pointed it out here #27329 (comment).

@NetWilliam - You will have to provide good counter-arguments as to why you believe a goroutine id is necessary. You are proposing to change one of the major features of the language, so unless the benefits outweigh the disadvantages due to added API, it is unlikely to be accepted. Just mentioning "debugging" is not very helpful.

[rsc]

In general logical work can move around between goroutines. What you want is to print, explicitly, some indicator of the work being done, and then you can correlate log prints. Like it says in the FAQ and other places, we don't want to give any special meaning to goroutine identity.

Note also that if you are trying to understand the goroutine behavior explicitly, there is the runtime tracer (go tool trace).