On Sat, Oct 1, 2022 at 8:35 AM Robert Engels <reng...@ix.netcom.com> wrote:
> I read the structured concurrency paper and it indeed formalizes the ideas > I derived from the original paper. If you review the examples it is implied > that the context is supplied to workers via thread locals. The ideas > presented in this paper define clearly what is lacking in the Go model - > that the concurrency is unstructured and it leads to difficult to > understand stack traces. > This is an extreme stretch to me. Note that Java's concurrency is also unstructured, with virtual threads as well. In both cases, the language and runtime provide concurrency primitives which are then used and composed into higher level programming models. The StructuredTaskScope is one way in which Java supports structured concurrency on top of their unstructured concurrency model. errgroup.Group and similar APIs are ways in which Go supports structured concurrency on top of the unstructured concurrency model. There is no real contradiction here. The one difference is that Java has TLS and Go doesn't. That's unambiguously true, but there are reasons for that. Those reasons aren't really addressed by anything I've read so far. And I think that's fine. I, personally, wouldn't go so far as to say it's *bad* that Java has TLS, just as little as I would say it's bad that Go doesn't have it. TLS has benefits and it has downsides and it is entirely reasonable for two programming languages to make different decisions about their inclusion. Note that TLS (or GLS) and similar primitives *are* periodically talked about and I don't think it is categorically excluded to at least get primitives which address *some* of the uses. sync.Pool is one such example. However, Go tries to be careful about it and instead of adding general TLS, which can be used for things it would consider good *and* bad, rather talks about each individual use case built on top of it separately and tries to forge them into APIs which allow for the good and prevent the bad. A context.Context in TLS has so far been rejected because it seems the bad outweighs the good. > > If a thread only exists to service a “request” it defacto represents the > context so if you have the facility to carry context related state with the > thread it eliminates the need to explicitly pass it as method parameters. > > On Oct 1, 2022, at 1:19 AM, Bakul Shah <ba...@iitbombay.org> wrote: > > 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 > 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/DD955473-8C00-40BA-A11E-DE94BC01F80E%40iitbombay.org > <https://groups.google.com/d/msgid/golang-nuts/DD955473-8C00-40BA-A11E-DE94BC01F80E%40iitbombay.org?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/CAEkBMfG%2BzKQqUGLCVe4cxrcYn50yqxN3EW%2BhfXL%3DcnBjGfDhsg%40mail.gmail.com.
