is there a goroutine scope global veriable ?

[hui zhang]

I write logs into one single log file.

and need to set a different tracking id for each goroutine.

But I don't want to pass the tracking id argument for all functions.

func main() {
  go Func()
}
func Func() {
  SetLogTrackId("xxxx")
  LogDebug("123")
  call1()
}
func call1() {
   LogDebug("call1")
}
var trackId string //need this scope to be goroutine scope
func SetLogTrackId(id string) {
    trackId = id
}
func LogDebug(v ...interface{}) {
    log.Println("DEBUG " + trackId + " " + fmt.Sprintln(v...))
}

[hui zhang]

is there a goroutine scope global veriable ?
like  fork a variable from main ?

[Kurtis Rader]

On Tue, Jun 18, 2019 at 7:56 PM hui zhang <fastf...@gmail.com> wrote:

is there a goroutine scope global veriable ?   so  I can do this ?

You're asking if Go supports the equivalent of thread local storage as used in Java, C++, and Python. The answer is, no. See https://stackoverflow.com/questions/31932945/does-go-have-something-like-threadlocal-from-java and https://github.com/golang/go/issues/21355

--

Kurtis Rader

Caretaker of the exceptional canines Junior and Hank

[Jan Mercl]

On Wed, Jun 19, 2019 at 4:55 AM hui zhang <fastf...@gmail.com> wrote:

> is there a goroutine scope global veriable ? so I can do this ?

Go has no global scope. The closest is universe scope but that scope
contains only predeclared identifiers. I think you are meaning package
scope.

Goroutines can access variables visible to them in any scope, but the
only ones that are private to the goroutine have block scope.

[hui zhang]

thanks ,  I also google blew links.

It is called goroutine local storage （gls）  and  many third party implement(https://github.com/jtolds/gls)

however,   the golang official suggest to use go context.

but, very few document mention , how to do it as goroutine local storage .  Can anyone give an example to solve my problem , refer the code I attached?

在 2019年6月19日星期三 UTC+8上午11:03:59，Kurtis Rader写道：

[Jan Mercl]

On Wed, Jun 19, 2019 at 10:41 AM hui zhang <fastf...@gmail.com> wrote:

> but, very few document mention , how to do it as goroutine local storage . Can anyone give an example to solve my problem , refer the code I attached?

Make the goroutine a method of a struct that contains any context the
goroutine needs. The data in the struct becomes your goroutine-local
storage.

type gls struct { id int }

func newG(id int) {
g := &gls{id}
go g.run()
}

func (g *gls) run() { fmt.Println(g.id) }

[hui zhang]

thank you very much. 

Is there a  golang context way to do it?

在 2019年6月19日星期三 UTC+8下午4:55:09，Jan Mercl写道：

[Jan Mercl]

On Wed, Jun 19, 2019 at 11:15 AM hui zhang <fastf...@gmail.com> wrote:

> Is there a golang context way to do it?

Some bits are at https://golang.org/pkg/context/#pkg-examples

[hui zhang]

this implement does not solve the problem.

still need pass the parameter in all functions.

func (g *gls) run()    or    func run (g *gls)

在 2019年6月19日星期三 UTC+8下午4:55:09，Jan Mercl写道：

On Wed, Jun 19, 2019 at 10:41 AM hui zhang <fastf...@gmail.com> wrote:

[jake...@gmail.com]

This has been discussed many times before. Searching "local storage" on this group brings up many discussions, including:

https://groups.google.com/d/topic/golang-nuts/Nt0hVV_nqHE/discussion

https://groups.google.com/d/topic/golang-nuts/_Vv7Bzn8yH4/discussion

https://groups.google.com/d/topic/golang-nuts/zuWWBHKn6iw/discussion

My take is that GLS could be genuinely useful in a few cases, but would undoubtedly lead to abuse in most cases. In the vast majority of  situations, what you really want to track, or log, is the specific work being done, not actually which goroutine it happens to be running on. For example, tracking a specific request, etc. My advice is to pass around a context, or some other identifying information about the specific work being done. At first this will seem tedious and annoying, but you will likely get used to it.

[Robert Engels]

Side-managed thread/execution context has been around since the concept of a thread. It is highly useful, and is more robust and secure than a Context object passed among methods.

If Go had any concept of a "secure runtime" it would be essential, but it doesn't, so you make do with what you have.

--
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/53512dd1-8c24-460d-9bf5-646ea1e95d0f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Jones]

For the OP:

A thought to share on the general topic: Go is pioneering a sufficiently different model of concurrent computation that it may not make much sense to ask for or seek equivalencies with classic thread/process models. 

This says nothing against the standard model, nor against the “missing” services; it is a note to encourage design in Go along with coding in Go, instead of design in C/C++/Java/POSIX/... and a best-effort realization in Go. 

By way of analogy, I’ve long been involved in boat design and construction. We always use a pair Furuno or Simrad RADAR antennas, one of long range and one short, to optimize object detection/clutter rejection and as a redundancy safety factor. However, when sailing on a HobeeCat, i’ve never looked for nor missed the Radar or any other instruments of navigation. A HobieCat is just such a different idea of sailing that *all* the normal mechanisms have no place.  There is no “where do I stow the anchor” or “where do I control the RAM signal lights.” There are whole chapters of the USCG instructions (ColRegs) where the thing discussed is not on a HobeeCat. That does not make such boats inadequate; it makes them fun. 

If you can stop thinking of concurrency in Go as a small group of exquisitely instrumented machines and instead imagine a swarm of ants, you’ll find new and interesting ways to solve problems. They often work even better, and are also more fun. 

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1187971360.3926.1560962237733%40wamui-berry.atl.sa.earthlink.net.

For more options, visit https://groups.google.com/d/optout.

--

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

[Henrik Johansson]

On a practical note I think thread local storage is more or less discouraged in for example Java as well

because it makes all the new shine "reactive" tools break since they make no guarantees as to which thread you are running on.

That may or may not be relevant to your case but to say that it's standard practice is probably not true any more.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CALoEmQy_p7hs%3DxrWGFx65r7xb63wGi_dg6aL6PRFfG7%2BwFP7-Q%40mail.gmail.com.

[Robert Engels]

Yes, Windows 3.1 is new again... A primary benefit for Go - lightweight parallelism and concurrency of procedural functions - is thrown out the "window" with reactive style programming. No need to use reactive if using Go properly.

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