On Saturday, September 26, 2020 at 5:41:54 AM UTC-7 rog wrote: > 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. > Worker pools with long-lived goroutines are actually very rare in Go, because launching a new goroutine is easy. A worker pool that is created in-place (for example, to run parallel processing on data) would work just fine.
-- 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/fddb15ae-876c-48f4-83d2-d9a6e43b73c4n%40googlegroups.com.
