Oh, following the link about Structured Concurrency at the end brings you to 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> 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> > 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/CAEkBMfEO-LVU_09itMwjdF-ciN_k9Dz_LthtWwgisMMz%2BQbMnw%40mail.gmail.com.
