On Sat, Oct 1, 2022 at 8:06 AM Robert Engels <reng...@ix.netcom.com> wrote:
> 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. > Yes, that' why I said "if anything" - it certainly doesn't say "use them more", it says "stop using them for $things" (where $things is what we use sync.Pool for). > 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 don't believe this is necessarily true. Note that `net/http` does this, but it still requires an explicit context for cancellation etc. I've now read JEP 428 (Structured Concurrency) as well, which *is* a lot closer to talk about context.Context, in that it actually does address cancellation. In effect, it seems to propose a programming API that is very close to Go's errgroup, with a bit of enforcement from the runtime. Basically, they say that in Structured Concurrency, tasks should be organized into trees of tasks. A subtree of tasks is managed together - it is cancelled together, it fails together and before a task is finished, it must join all its subtasks. I find myself agreeing with all of this. Structured Concurrency is a very good programming model for Go as well and it's one I use it in my own programs as well. It really is how errgroup is used, with the exception that subtasks can cancel their parents as well. The main difference to errgroup is that the StructuredTaskScope (roughly corresponding to a combination of *errgroup.Group and the context.Context) is stored in thread local storage and not passed explicitly. That's why I think it might be what you are referring to. One thing to note is that the authors explicitly *don't* propose to add channels though, which is how they avoid dealing with what Ian said. I think as soon as you get into using channels, the idea of storing the StructuredTaskScope in thread local storage breaks down. It's also noteworthy that this structured concurrency model is not the *only* programming model usable with virtual threads, just like not *all* goroutines have to be in an errgroup. And in fact, while I do like structured concurrency and use it as much as possible, there are cases where it makes sense *not* to use it. I think there is value in that flexibility, especially if we talk about a programming environment as a whole. The explicitness of context.Context is useful exactly in those cases where you stitch these different models together. Overall, I don't think JEP 428 contradicts Go's usage of context.Context at all. I think most Gophers I know will find they agree with the arguments. I just don't think they really make an argument in favor of using thread local storage over passing an explicit context - all of these articles mostly just seem to assume that TLS is used and good. In any case, I am happy to read the Java designers' thoughts on virtual threads and how they can improve programming. 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 >>> <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 > <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/CAEkBMfEKoCpWKXBXY2E-2gNHKUhyKYXzm2rFSFEWO9WThVw%3DWQ%40mail.gmail.com.
