Again, please read the paper. The arguments you make are refuted. The lack of routine context is a burden on the Go ecosystem and makes debugging highly concurrent Go systems far more difficult than similar systems in Java.
> On Sep 30, 2022, at 11:09 PM, Rob Pike <r...@golang.org> wrote: > > > 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/CAD38A60-EE4B-4A76-9F7B-66A9939874F5%40ix.netcom.com.
