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.
