[go-nuts] Re: Persistence of value, or Safely close what you expected

Note that you don't need to clean up a channel. The GC will automatically free the channel when there is no more reference to it. The only reason to close a channel is to send a signal to the other goroutines that you are done and there is no more data to send. Other than that, you don't need

[go-nuts] Re: Persistence of value, or Safely close what you expected

Thank you all very much for the discussion and suggestions. I decided to take a dive and opened proposal under https://github.com/golang/go/issues/30916 Any suggestions on improvements are welcome, but please keep in mind that I am not trying to solve my CURRENT problem at hand (it is

Re: [go-nuts] Re: Persistence of value, or Safely close what you expected

I am currently dealing with a race related bug, at least, I found a bug, and it coincided with a race when I enabled the race detector, and the bug is a deadlock, and the shared shut-down button clearly can be pressed on and off in the wrong order. So my first strategy in fixing the bug is

Re: [go-nuts] Re: Persistence of value, or Safely close what you expected

On Wed, Mar 13, 2019 at 4:01 PM Andrey Tcherepanov < xnow4fippy...@sneakemail.com> wrote: > Roger, it is not that I wondering it is async assignments are bad, it is > more of a question "why does it have to be SO complicated"? > > (please forgive me for a long ranty post) > > There were couple of

[go-nuts] Re: Persistence of value, or Safely close what you expected

You may have to copy-paste the playground link as clicking appears to load a previous version of the message that I deleted. (Not sure if this is just a bug on my end) -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this

[go-nuts] Re: Persistence of value, or Safely close what you expected

Hi, Just wanted to put it out there, that one way of handling a situation where you try to close on a chanel which may already be closed is to catch the panic with a recover like so: https://play.golang.org/p/nEeZ6ddXRR_O -K -- You received this

[go-nuts] Re: Persistence of value, or Safely close what you expected

Hi, Just wanted to put it out there, that one way of handling a situation where you try to close on a chanel which may already be closed is to catch the panic with a recover like so: https://play.golang.org/p/8uRq8J2TH2i -K -- You received this message because you are subscribed to the

Re: [go-nuts] Re: Persistence of value, or Safely close what you expected

Roger, it is not that I wondering it is async assignments are bad, it is more of a question "why does it have to be SO complicated"? (please forgive me for a long ranty post) There were couple of things I was implementing for our little in-house server app. One was (in)famous fan-out pattern

Re: [go-nuts] Re: Persistence of value, or Safely close what you expected

It might be helpful to have a better idea of what you're actually trying to do here. Specifically, why do you feel the need to assign to c concurrently? On Wed, 13 Mar 2019 at 16:38, Andrey Tcherepanov < xnow4fippy...@sneakemail.com> wrote: > Thank you Peter, I know that - I wrote that example

[go-nuts] Re: Persistence of value, or Safely close what you expected

Thank you Peter, I know that - I wrote that example on purpose to be undefined. To make it "well-defined" requires an enormous "fluff" which I am mentioned and trying to avoid. Andrey On Wednesday, March 13, 2019 at 9:02:53 AM UTC-6, peterGo wrote: > > Andrey, > > Your program has a data

[go-nuts] Re: Persistence of value, or Safely close what you expected

Andrey, Your program has a data race. The results are undefined. Data Race Detector https://golang.org/doc/articles/race_detector.html $ go run -race racer.go == WARNING: DATA RACE Write at 0x0050dfa0 by goroutine 6: main.niller() /home/peter/gopath/src/racer.go:6