To clarify a point that not be obvious - all of the routines involved in handling the request are temporary and only live through the life of the request - which defacto makes their existence = context, so using a thread local is simply a shorthand for passing the context to every method invoked by the routine.
> On Sep 30, 2022, at 11:12 PM, Robert Engels <reng...@ix.netcom.com> wrote: > > I disagree. I think if you read the article you’ll understand why. You need > to invert the context handling - the pattern you cite is exactly the pattern > the author describes but when you create the routines on demand and the > subordinate ones - the “thread” is the context and it removes the ugliness of > coloring every function in the path with a context variable. > > I think you’ll find the article interesting. It is certainly written by a CS > “god” that knows what he’s talking about. > >>> On Sep 30, 2022, at 10:39 PM, Ian Lance Taylor <i...@golang.org> wrote: >>> >>> On Fri, Sep 30, 2022 at 7:32 AM Robert Engels <reng...@ix.netcom.com> >>> wrote: >>> >>> Very interesting article came out recently. >>> https://www.infoq.com/articles/java-virtual-threads/ and it has >>> implications for the Go context discussion and the author makes a very good >>> case as to why using the thread local to hold the context - rather than >>> coloring every method in the chain is a better approach. If the “virtual >>> thread aka Go routine” is extremely cheap to create you are far better off >>> creating one per request than pooling - in fact pooling becomes an anti >>> pattern. If you are creating one per request then the thread/routine >>> becomes the context that is required. No need for a distinct Context to be >>> passed to every method. >> >> I didn't read the article (sorry). >> >> In a network server a Go context is normally specific to, and shared >> by, a group of goroutines acting on behalf of a single request. It is >> also normal for a goroutine group to manage access to some resource, >> in which case the context is passed in via a channel when invoking >> some action on behalf of some request. Neither pattern is a natural >> fit for a goroutine-local context. >> >> 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/CAOyqgcWAfdc2Np2KA%2B2-U9Z5Hv7tdHGgJHWDTUg_6pbr%3D8jghg%40mail.gmail.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/5FCE08D7-51D6-4104-91C5-6AD9B6EA880A%40ix.netcom.com.
