I've at least skimmed the article and I can't find any of the arguments you say are there. For thread locals it says, if anything, that they should be avoided with virtual threads - at least for some uses (the ones that you'd use a sync.Pool for in Go). On coloring it only talks about the advantages of virtual threads over async/await, which, well most Gophers will agree with.
Apart from these, I can't find anything that I could reasonably connect to context.Context - the article seems almost exclusively an introduction to virtual threads and an explanation on how they differ from operating system threads. In particular, I don't see anything in this article which could address the arguments Ian mentioned. It teases at more articles, about "Structured Concurrency" and "Extent local variables" - the latter sounds as if it *could* be what you talk about, but that article doesn't seem to exist yet. On Sat, Oct 1, 2022 at 6:15 AM Robert Engels <reng...@ix.netcom.com> wrote: > 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 > <https://groups.google.com/d/msgid/golang-nuts/CAD38A60-EE4B-4A76-9F7B-66A9939874F5%40ix.netcom.com?utm_medium=email&utm_source=footer> > . > -- 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/CAEkBMfGMQNtAwgqA75Dz6n3BqVeNHDjVAv0LieuEn2hJgvQV%3DA%40mail.gmail.com.
