On Wed, Sep 23, 2020 at 6:02 PM Alex Mills <a...@channelmeter.com> wrote: > > Not a joke, in terms of performance, if you access the goroutine id via the C > library call?
I'm not sure what C library call you mean. > My only concern would be if goroutine id's were reused, if not it would work. Goroutine IDs are not reused. (Well, a goroutine ID is just a 64-bit integer so it could technically wrap around and be reused in that way, but it seems unlikely.) Ian > On Wed, Sep 23, 2020 at 5:54 PM Ian Lance Taylor <i...@golang.org> wrote: >> >> On Wed, Sep 23, 2020 at 5:46 PM Alex Mills <a...@channelmeter.com> wrote: >> > >> > There appears to be a way to get a reference on the goroutine id: >> > >> > http://blog.sgmansfield.com/2015/12/goroutine-ids/ >> >> But as you can see by reading that blog article, that is almost a joke. >> >> Go considers these things to be better handled explicitly, which is >> why people are telling you to use a context.Context value. And, yes, >> you'll want to use a Context aware logging package. >> >> In Go it's trivial to create new goroutines, and as soon as you do >> that any goroutine-local-variable scheme falls apart. So Go has >> consistently chosen to not provide that capability, and similarly to >> not provide goroutine IDs. It's an intentional choice by the >> language. There have been a number of discussions about this in the >> past on this mailing list. >> >> Ian -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUsLyVurqXqt6GDgMBQYcoVK%2BP4%2Bdm14ju-VKiA%3Dh1jYg%40mail.gmail.com.
