faq: document why there is no way to get a goroutine ID #22770
Comments
|
There are additional reasons. The C pain of thread local storage infecting users of libraries should be mentioned. |
|
@bradfitz Please expand. |
|
A classic example is graphics libraries that require that all operations be performed on "the main thread", because that's where some library stashed away its state, in TLS, and if you call from any other thread, you crash. It's why we have gunk like https://golang.org/pkg/runtime/#LockOSThread. It's why tracing is both magic & prone to break mysteriously inside Google in Java and C++, because it's magic until it no longer works at all, if you do something on the wrong thread. In Go, we want to make sure regular code can create & use & forget about goroutines casually, and be able to call any code from any goroutine, without treating any particular goroutines as special. |
|
|
Change https://golang.org/cl/80195 mentions this issue: |
We've deliberately decided that there should be no way to get a goroutine ID, and there is no goroutine local storage. Since this comes up from time to time, we should add the explanation to the FAQ.
Here is an explanation I just wrote which may serve as a starting point:
It's because Go makes it cheap to start new goroutines, and it is normal in Go for a single task to be implemented by a collection of goroutines. Some of those goroutines may be newly started, some may be long running goroutines that provide some service. Of course one must aggregate log entries and other information for a single task, but because multiple goroutines are routinely involved in performing a single task, using a goroutine ID is the wrong approach. It is a temptation that one may naturally reach for when starting to write a program that uses a single goroutine, but that then breaks as the program evolves to use multiple goroutines. Just as Go prohibits things like unused imports, it prohibits this temptation. The intent is to force you to start writing your program the way it is going to wind up anyhow.
There are obviously many other approaches and the point is that they work with multiple goroutines and they are explicit in the program source rather than implicit in the program execution.
The text was updated successfully, but these errors were encountered: