One of the critical decisions in Go was not defining names for goroutines. If we give threads/goroutines/coroutines (TGCs) names or other identifiable state, such as contexts, there arises a tendency to push everything into one TGC. We see what this causes with the graphics thread in most modern graphics libraries, especially when using a threading-capable language such as Go. You are restricted in what you can do on that thread, or you need to do some sort of bottlenecking dance to have the full language available and still honoring the requirements of a single graphics thread.
One way to see see what this means: Long ago, people talked of a "thread per request" model, and honestly it was, or would have been, an improvement on standard practice at the time. But if you have cheap TGCs, there is no need to stop there: You can use multiple independently executing TGCs to handle a request, or share a TGC between requests for some part of the work (think database access, for example). You have *the whole language available to you* when programming a request, including the ability to use TGCs. Like Ian, I have not read this paper, but I take it as a tenet that it is better to keep goroutines anonymous and state-free, and not to bind any particular calculation or data set to one thread of control *as part of the programming model*. If you want to do that, sure, go for it, but it's far too restrictive to demand it *a priori* and force it on others*.* -rob On Sat, Oct 1, 2022 at 1: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/CAOXNBZRTgLSos4CXjHRV6zgu-8eLjxn2mYHjo%3DXMmw-Td4gz6g%40mail.gmail.com.
