Re: [go-nuts] Go routine context

On Sun, Oct 2, 2022, 4:46 PM Sven Anderson wrote: > Ian Lance Taylor schrieb am Sa. 1. Okt. 2022 um 17:12: > >> >> Another example of goroutine-local storage that we currently support >> is runtime/pprof.Do, which adds labels to the current goroutine. This >> seems OK as the labels are readonly

Re: [go-nuts] Go routine context

On Mon, 2022-10-03 at 00:46 +0200, Sven Anderson wrote: > As it happens, I wrote a small package, that does that „almost“ > legally:  > https://pkg.go.dev/github.com/ansiwen/gctx There is also github.com/kortschak/goroutine for getting goroutine IDs, which can be used as the primitive for construc

Re: [go-nuts] Go routine context

Ian Lance Taylor schrieb am Sa. 1. Okt. 2022 um 17:12: > > Another example of goroutine-local storage that we currently support > is runtime/pprof.Do, which adds labels to the current goroutine. This > seems OK as the labels are readonly and are inherited by goroutines > started with a go statem

Re: [go-nuts] Go routine context

Can we collectively stay calm and within the bounds of polite discourse? The overall tone of this thread is pretty aggressive. I would also like to point out that this particular topic of discussion - the credentials of the author of the original article - seem fallacious to me from either side. T

Re: [go-nuts] Go routine context

On Sun, Oct 2, 2022 at 3:00 PM Robert Engels wrote: > They are still non-preemptive. Even the way preemption is implemented is > cooperative. Goroutines are preempted in a thread signal handler that invokes the Go runtime scheduler that in turn saves the required goroutine state and switches th

Re: [go-nuts] Go routine context

On Sun, Oct 2, 2022 at 3:04 PM Robert Engels wrote: > One other thing, if you don’t think he knows exactly how Go routines are > implemented you are delusional. Maybe he should then fix the Wikipedia article I linked before. Good luck with that. PS: I assume you meant "goroutines" instead of "

Re: [go-nuts] Go routine context

On Sun, Oct 2, 2022 at 2:47 PM Robert Engels wrote: > I already pointed that out.Go routines were non preemptive until recently. > They are also still non preemptive when calling a system call without direct > support, or CGo - it spins up another platform thread. I'm talking about a principal

Re: [go-nuts] Go routine context

Thank you. Great interview. As expected, everything he said was true - especially when you read the full segment - one in about 50 presented. No wonder the original poster did not want to link to the full article. I’ll reiterate - “CS god”. I did a quick review of k8s - and it is almost equal

Re: [go-nuts] Go routine context

On Sun, Oct 2, 2022 at 1:16 PM Robert Engels wrote: > By many definitions Go routines and virtual threads are technically > coroutines - versus a platform/OS thread. Show one please. Coroutines are normally a subject of non-preemptive multitasking, threads are normally just the opposite. [0]

Re: [go-nuts] Go routine context

On Sun, 2022-10-02 at 06:15 -0500, Robert Engels wrote: > Again, I would like a link to the source of statement to evaluate it > in context.  https://manningbooks.medium.com/interview-with-brian-goetz-7d6c47d05d63 -- You received this message because you are subscribed to the Google Groups "gol

Re: [go-nuts] Go routine context

Also, until fairly recently Go routines were non preemptive- making them even closer to a coroutine. I have no idea when this statement was made to judge that aspect as well. > On Oct 2, 2022, at 6:15 AM, Robert Engels wrote: > >  > By many definitions Go routines and virtual threads are tec

Re: [go-nuts] Go routine context

By many definitions Go routines and virtual threads are technically coroutines - versus a platform/OS thread. Again, I would like a link to the source of statement to evaluate it in context. > On Oct 2, 2022, at 5:32 AM, w54n wrote: > > Not an entirely true statement, and a fairly misunder

Re: [go-nuts] Go routine context

Not an entirely true statement, and a fairly misunderstanding of the subject. On Saturday, October 1, 2022 at 11:13:19 PM UTC+2 al...@pbrane.org wrote: > Robert Engels once said: > > I think you’ll find the article interesting. It is certainly written > > by a CS “god” that knows what he’s ta

Re: [go-nuts] Go routine context

On Sun, Oct 2, 2022 at 1:37 AM Robert Engels wrote: > I don’t see any arguments refuting the claim? Can you include a link so the > analysis can be read in context? The word "coroutines" does not ring a bell? -- You received this message because you are subscribed to the Google Groups "golan

Re: [go-nuts] Go routine context

I don’t see any arguments refuting the claim? Can you include a link so the analysis can be read in context? > On Oct 1, 2022, at 4:13 PM, Anthony Martin wrote: > > Robert Engels once said: >> I think you’ll find the article interesting. It is certainly written >> by a CS “god” that knows wha

Re: [go-nuts] Go routine context

Robert Engels once said: > I think you’ll find the article interesting. It is certainly written > by a CS “god” that knows what he’s talking about. This is the same "god" that said: "Everyone thinks that the concurrency model is Go’s secret weapon, but I think their concurrency m

Re: [go-nuts] Go routine context

I admit that I probably read into that based on the historical use of ThreadLocals to carry context in traditional ‘request is a thread’ systems. I think as Axel pointed out it is more explicit in the ’structured concurrency’ paper. In Java the Thread has always carried context - it is used in

Re: [go-nuts] Go routine context

On Fri, Sep 30, 2022 at 11:47 PM 'Axel Wagner' via golang-nuts wrote: > > 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. H

Re: [go-nuts] Go routine context

I have now read JEP 429 Extent-local variables (ELV) , which is probably the most salient for the discussion about context.Context. ELV allow to "bind" values a variable in a way that is local to a (virtual) thread. Those values are AIUI not always inherited to child

Re: [go-nuts] Go routine context

On Sat, Oct 1, 2022 at 8:35 AM Robert Engels 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

Re: [go-nuts] Go routine context

On Sat, Oct 1, 2022 at 8:06 AM Robert Engels 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.

Re: [go-nuts] Go routine context

Quoting from this article: "Virtual threads (JEP 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

Re: [go-nuts] Go routine context

I did a quick read. Virtual threads seems much *closer* to goroutines and they suggest people "unlearn" the overuse of thread local storage (TLS)! The thread pooling they talk about is to avoid the much higher thread creation time -- not a problem in Go. > On Sep 30, 2022, at 9:08 PM, Rob Pike

Re: [go-nuts] Go routine context

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 rere

Re: [go-nuts] Go routine context

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 wrote: > I've at least skimmed t

Re: [go-nuts] Go routine context

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 advantage

Re: [go-nuts] Go routine context

To clarify a point that not be obvious - all of the routines involved in handling the request are temporary and only live through the life of the request - which defacto makes their existence = context, so using a thread local is simply a shorthand for passing the context to every method invoked

Re: [go-nuts] Go routine context

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 wrote: > >  > One of the cr

Re: [go-nuts] Go routine context

I disagree. I think if you read the article you’ll understand why. You need to invert the context handling - the pattern you cite is exactly the pattern the author describes but when you create the routines on demand and the subordinate ones - the “thread” is the context and it removes the uglin

Re: [go-nuts] Go routine context

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 gr

Re: [go-nuts] Go routine context

On Fri, Sep 30, 2022 at 7:32 AM Robert Engels 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 th

Re: [go-nuts] Go routine context

Java has an InheritableThreadLocal for that very reason - that is automatically propagated and the child can subsequently override if needed. > On Sep 30, 2022, at 9:43 AM, Ian Davis wrote: > >  >> On Fri, 30 Sep 2022, at 3:32 PM, Robert Engels wrote: >> Very interesting article came out rece

Re: [go-nuts] Go routine context

On Fri, 30 Sep 2022, at 3:32 PM, Robert Engels 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

[go-nuts] Go routine context

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