Re: [go-nuts] Re: is there a goroutine scope global veriable ?

Thu, 20 Jun 2019 08:11:15 -0700


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.
-----Original Message-----
From: Henrik Johansson
Sent: Jun 20, 2019 2:46 AM
To: Michael Jones
Cc: Robert Engels , golang-nuts , jake6...@gmail.com
Subject: Re: [go-nuts] Re: is there a goroutine scope global veriable ?

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.

On Wed, Jun 19, 2019 at 8:49 PM Michael Jones <michael.jo...@gmail.com> wrote:
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. 

On Wed, Jun 19, 2019 at 9:37 AM Robert Engels <reng...@ix.netcom.com> wrote:
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.


-----Original Message-----
From: jake6...@gmail.com
Sent: Jun 19, 2019 11:08 AM
To: golang-nuts
Subject: [go-nuts] Re: is there a goroutine scope global veriable ?

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


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.


On Tuesday, June 18, 2019 at 10:59:09 PM UTC-4, hui zhang wrote:
is there a goroutine scope global veriable ?
like  fork a variable from main ?

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







-- 

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/1187971360.3926.1560962237733%40wamui-berry.atl.sa.earthlink.net.

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


-- 
Michael T. Jones
michael.jo...@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/CALoEmQy_p7hs%3DxrWGFx65r7xb63wGi_dg6aL6PRFfG7%2BwFP7-Q%40mail.gmail.com.

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







-- 

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/CAKOF695n5b0xQENWZK-hS1MUZ7ezGVBM9wRj6Vhr1eJDam%3DaEQ%40mail.gmail.com.

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










-- 

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/577648200.3501.1561043446308%40wamui-charming.atl.sa.earthlink.net.

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






















					Reply via email to