Is there a way to create a global variable inside go routine stack? so that i can access any time, without passing around between methods/functions. Crazy thought !!!..

[adithya...@gmail.com]

Is there a way to create a global variable inside go routine stack? so that i can access any time, without passing around between methods/functions. Crazy thought !!!..

[robert engels]

Use a package exported (public) variable.

On May 23, 2020, at 2:34 PM, adithya...@gmail.com wrote:

Is there a way to create a global variable inside go routine stack? so that i can access any time, without passing around between methods/functions. Crazy thought !!!..

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1f790fd5-437f-4a8c-8122-5d6b05841117%40googlegroups.com.

[Sam Whited]

You are describing a thread-local variable (or a goroutine local
variable, I suppose). The Go authors didn't feel this was an appropriate
feature for Go and it is not supported.

You may find some third party libraries that do this by parsing stack
traces and using them to index into maps or similar techniques, but
these could break at any moment and you should avoid them at all costs.

—Sam

--
Sam Whited

[Robert Engels]

Ignore, didn’t see the stack statement. 

[sa...@silverslanellc.com]

Variable scope is a textual (special if you like) concept. Go routines are a temporal concept. Does it make sense to think about a global variable in this way?

[adithya...@gmail.com]

if i am not wrong, Even the main itself is a go routine, which have global variables?

[tokers]

You may try to inspect this go package: https://github.com/jtolio/gls

[adithya...@gmail.com]

Yeah this works, but you can say this as workaround, what i really want is, does native go support? if not why?

[Michael Jones]

Variables are names associated with values, values that can vary, that is, can be changed. (Unlike constants, which are constant values.)

In the beginning, all variables were global, and this was not good. 

Then came local variables, ones local to a function, which came and went as functions executed, and then block-scoped variables, ones local to a particular begin...end or {...} block of code. This was seen as good, and the people were urged to avoid global variables (and goto and other ways of the past).

Now, every combination of ways has a home in some language's culture: static in C is a function-local global variable, Go style embraces global variables for flag values, and there are local variables in sophisticated assembly languages that never go to memory. 

Now, what problem is it exactly that you want to solve?

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3e71bdf8-3b99-4f47-9412-68cc50f69e84%40googlegroups.com.

--

Michael T. Jones
michae...@gmail.com

[Jake Montgomery]

On Sunday, May 24, 2020 at 3:46:54 PM UTC-4, adithya...@gmail.com wrote:

if i am not wrong, Even the main itself is a go routine, which have global variables?

Perhaps you should describe a bit more what you mean? People seem to be making assumptions that you meant something different that what you actually said. Assuming you are referring to the main() function, then, no it is not a goroutine, but it does run in a goroutine. However, main() doe not "have" global variables. Can you give an exmaple of what you mean by this?

Global variables belong to the package, and are accessible from any goroutine in the package, if they are private, and from any goroutine anywhere if they are public.

[Jon Perryman]

Each package has a set of global variables. Adding another set of globals for each executing Goroutine would be too complex. Functions are not specific to Goroutine, but a second global pool would require additional considerations specific to goroutine vs main. 

What is the drawback to passing the goroutine global variables as a struct to each function? It's certainly far less overhead than the workaround and it follows standard GO conventions. 

<pre>

package main

import (
    "fmt"
    "time"
    "sync"
)

func main() {

    go goroutine()
    go goroutine()
    go goroutine()
    go goroutine()

    time.Sleep(time.Second)
    fmt.Println("all done")
}

type Global struct {
    Id int
    Name string
    Cnt int
}

var goroutineCount int = 0

func goroutine() {
    mutex := &sync.Mutex{}
    mutex.Lock()
    goroutineCount++
    mutex.Unlock()
    g := Global{
        Id : goroutineCount,
        Name : "some name",
        Cnt : 100,
    }
    g.Method1()
}

func (g *Global) Method1() {
    g.Method2()
    g.Cnt++
    fmt.Println("method1", g.Id, g.Name, g.Cnt)
}

func (g *Global) Method2() {
    g.Cnt++
    fmt.Println("method2", g.Id, g.Name, g.Cnt)
}

</pre>

Jon.

[Robert Engels]

You want the gls package referenced earlier. 

Go doesn’t have it built in because the designers don’t like it or feel it is necessary. You can find and read the GitHub issue that covers thread/go local storage. 

On May 26, 2020, at 8:04 PM, Jon Perryman <jon.pe...@gmail.com> wrote:



--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAByJhJnn6uLbcM_JBBV%3DJewBQB5iztb23BYHAO98Bvf2nTkPUQ%40mail.gmail.com.

[adithya...@gmail.com]

https://github.com/golang/go/issues/21355, this is the issue i am reffering to.

[adithya...@gmail.com]

This is issue i am referring to https://github.com/golang/go/issues/21355.

On Monday, May 25, 2020 at 10:21:19 PM UTC+5:30, Michael Jones wrote:

Variables are names associated with values, values that can vary, that is, can be changed. (Unlike constants, which are constant values.)

In the beginning, all variables were global, and this was not good. 

Then came local variables, ones local to a function, which came and went as functions executed, and then block-scoped variables, ones local to a particular begin...end or {...} block of code. This was seen as good, and the people were urged to avoid global variables (and goto and other ways of the past).

Now, every combination of ways has a home in some language's culture: static in C is a function-local global variable, Go style embraces global variables for flag values, and there are local variables in sophisticated assembly languages that never go to memory. 

Now, what problem is it exactly that you want to solve?

On Sun, May 24, 2020 at 11:06 PM <adithya...@gmail.com> wrote:

Yeah this works, but you can say this as workaround, what i really want is, does native go support? if not why?

On Monday, May 25, 2020 at 7:57:17 AM UTC+5:30, tokers wrote:

You may try to inspect this go package: https://github.com/jtolio/gls

--
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 golan...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3e71bdf8-3b99-4f47-9412-68cc50f69e84%40googlegroups.com.

[adithya...@gmail.com]

Thanx. This i thought but i want context as "Global" struct, which i cant do.

Anyhow please refer https://github.com/golang/go/issues/21355

[adithya...@gmail.com]

Yeah same problem. 

On Wednesday, May 27, 2020 at 8:03:35 AM UTC+5:30, Robert Engels wrote:

You want the gls package referenced earlier. 

Go doesn’t have it built in because the designers don’t like it or feel it is necessary. You can find and read the GitHub issue that covers thread/go local storage. 

To unsubscribe from this group and stop receiving emails from it, send an email to golan...@googlegroups.com.

[robert engels]

As the issue concludes - it was decided against. So, nothing to see here folks.

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/4ace5c86-1895-4090-90ff-68be45454bdf%40googlegroups.com.

[robert engels]

Your use of the word “Global” in this sense is very non-standard. What the issue refers to is TLS/GLS which is scoped by the Go routine - regular exported variables are “global”.

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/88474b1b-827e-4dcb-a56e-b942fafe71b8%40googlegroups.com.