On Sat, 26 Sep 2020, 02:36 Alex Besogonov, <alex.besogo...@gmail.com> wrote:
> On Friday, September 25, 2020 at 4:43:45 PM UTC-7 Ian Lance Taylor wrote: > >> On Fri, Sep 25, 2020 at 10:35 AM Alex Besogonov >> <alex.be...@gmail.com> wrote: >> > >> > Inheritable goroutine-locals would actually work just fine in Go. >> Moreover, Go actually has them in the form of pprof labels. >> What should happen if one goroutine changes an inherited >> goroutine-local variable? >> > A Go-style goroutine-local system can be thought as a context.Context that > is transparently assigned to a goroutine and its children. Thus if you want > to change the value, you'd do something like "c := > magic.GetCurrentContext(); c = c.WithValue(...); magic.SetContext(c);". > > This would affect only the current goroutine going forward, but not its > children. > What happens if you want to invoke an operation by passing its arguments to an existing goroutine that does work on the current goroutine's behalf (aka a worker pool)? I don't think this pattern is that uncommon, and it would break the inheritable-variables model. > > >> > On Wednesday, September 23, 2020 at 5:55:50 PM UTC-7 Ian Lance Taylor >> wrote: >> >> >> >> On Wed, Sep 23, 2020 at 5:46 PM Alex Mills <al...@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...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/f78f2d12-89d2-494d-983a-a462f0124d82n%40googlegroups.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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/7bc62278-5cbc-47fe-abd2-36172e4e8520n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/7bc62278-5cbc-47fe-abd2-36172e4e8520n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAJhgacifKxQVzq%3Dak%2BCzR_5GX-1C5_%3DdV6awwkbaDNrn40MVYA%40mail.gmail.com.
