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

[go-nuts] Re: Encrypting credentials config file in production and pseudo key rotation

I'm not sure what your threat model is, but I note that if you dump both the encrypted data and the key to the filesystem, then the original secret data is trivially recoverable. And with most filesystems, if you delete a file, the data is still recoverable. I would suggest using an external s

[go-nuts] Encrypting credentials config file in production and pseudo key rotation

Hello World This relates to that never ending question of securing the credentials in production/staging envs, that is, avoiding storing them as plain text I am wondering if anyone could share their thoughts about the following approach we are thinking of taking. Here we go: During build phas

Re: [go-nuts] How is the relationship between package version and tag, and what is the formation mechanism?

Hi, This is documented in the Go module documentation here: https://go.dev/ref/mod#vcs-version cheers, rog. On Thu, 29 Sept 2022 at 18:29, 'Jinchang Hu' via golang-nuts < golang-nuts@googlegroups.com> wrote: > When we use go list -m dependencyName@Version to get the specific > information

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

[go-nuts] Re: Creating and Accessing DLL methods in GO

> is go-plugin supported by Windows? If you mean go's own plugin system, then no: https://pkg.go.dev/plugin (sorry, I should have remembered that) If you mean the go-plugin library from Hashicorp: I believe it should be fine. It's used by Hashicorp Vault, and Vault supports Windows: https://ww

[go-nuts] Re: go program import ?

Hi, I have found data necessary to me there: go/build.Default.GOROOT in case someone is in interest. Thank you. четверг, 29 сентября 2022 г. в 20:59:50 UTC+3, alex-coder: > Hi All, > > How I could detect programmatically that import in a go code > belongs to a go distribution ? > > thank you v

[go-nuts] Go implementation of CLP

Seems there are no Go implementation for Compressed Log Processor (CLP) yet? CLP is a tool capable of losslessly compressing text logs and searching the compressed logs without decompression. https://github.com/y-scope/clp Chris -- You received this message because you are subscribed to the