Quoting from this article: "Virtual threads (JEP 425 <https://openjdk.org/jeps/425>) make it cost-effective to dedicate a thread to every such I/O operation, but managing the huge number of threads that can result remains a challenge."
My quick take: may be this is due to "old thread think" as virtual threads are so new in Java? Has managing large number of goroutines been a problem? One use I can see for giving each thread a handle is for doing user level scheduling and in general treating them as first class objects. This may be a cost vs benefit issue. > On Sep 30, 2022, at 10:49 PM, 'Axel Wagner' via golang-nuts > <golang-nuts@googlegroups.com> wrote: > > Oh, following the link about Structured Concurrency at the end brings you to > https://openjdk.org/jeps/428 <https://openjdk.org/jeps/428> > That *does* indeed seem to contain discussion about relevant topics. Perhaps > that's the link you intended to post? > > On Sat, Oct 1, 2022 at 7:45 AM Axel Wagner <axel.wagner...@googlemail.com > <mailto:axel.wagner...@googlemail.com>> wrote: > 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 > <mailto: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 >> <mailto: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 >> <mailto:i...@golang.org>> wrote: >> On Fri, Sep 30, 2022 at 7:32 AM Robert Engels <reng...@ix.netcom.com >> <mailto:reng...@ix.netcom.com>> wrote: >> > >> > Very interesting article came out recently. >> > https://www.infoq.com/articles/java-virtual-threads/ >> > <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 >> <mailto:golang-nuts%2bunsubscr...@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 >> >> <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 > <mailto: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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEO-LVU_09itMwjdF-ciN_k9Dz_LthtWwgisMMz%2BQbMnw%40mail.gmail.com > > <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEO-LVU_09itMwjdF-ciN_k9Dz_LthtWwgisMMz%2BQbMnw%40mail.gmail.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/DD955473-8C00-40BA-A11E-DE94BC01F80E%40iitbombay.org.
