I think the article I cited presents the argument. (I’m on mobile so a bit hamstrung). The section on thread locals doesn’t say to avoid them. It says to avoid them for caching - as the virtual thread should be temporary and not reused. Maybe the position is my own correlation (I’ll have to reread) but if the thread is temporary and only created to handle that request it is defacto the context for that request. I highly doubt I was smart enough to make that connection on my own :)
> On Oct 1, 2022, at 12:50 AM, '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 > 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. > > -- > 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. -- 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/311C556C-C44D-4F59-A805-5C46F3C3C151%40ix.netcom.com.
