On Fri, 30 Sep 2022, at 3:32 PM, Robert Engels 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 don't think it is usual to pool goroutines. Normal usage is to spin one up for each incoming request, which is the pattern used by Go's http server for example. I skimmed the article but my knowledge of Java's thread local storage is limited. In Go it's common for requests to spawn subrequests in their own goroutines. With a context you would derive a child context, potentially with a shorter lifetime. What is the equivalent in thread local storage? Is there a way to access parent thread storage from a child (analogous to how a child context has access to all the values assigned to the parent)? -- 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/b35520c7-87b2-4b83-be1b-2d2f4257d283%40app.fastmail.com.
