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 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 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 0x00000050dfa0 by goroutine 6: >> main.niller() >> /home/peter/gopath/src/racer.go:6 +0x3a >> >> Previous read at 0x00000050dfa0 by goroutine 5: >> main.closer() >> /home/peter/gopath/src/racer.go:10 +0x3a >> >> Goroutine 6 (running) created at: >> main.main() >> /home/peter/gopath/src/racer.go:18 +0xaa >> >> Goroutine 5 (finished) created at: >> main.main() >> /home/peter/gopath/src/racer.go:17 +0x92 >> ================== >> panic: close of closed channel >> >> goroutine 1 [running]: >> main.main() >> /home/peter/gopath/src/racer.go:23 +0xf4 >> exit status 2 >> $ >> >> Peter >> >> >> On Wednesday, March 13, 2019 at 2:40:30 AM UTC-4, Andrey Tcherepanov >> wrote: >>> >>> Hello fellow Go devs, >>> >>> I have a question that probably is a bit weird and obvious, but here we >>> go >>> >>> package main >>> >>> var c chan int >>> >>> func niller() { >>> c = nil >>> } >>> >>> func closer() { >>> close(c) >>> } >>> >>> func main() { >>> >>> c = make(chan int, 1) >>> >>> >>> go closer() >>> go niller() >>> >>> // checkpoint-1 >>> if c != nil { >>> // checkpoint-2 >>> close(c) >>> c = nil >>> } >>> } >>> >>> What are the guarantees (if any) that c, being non-nil at checkpoint-1 >>> will not become a nil at checkpoint-2? >>> >>> My take on it that there are none, and the code needs to be fully synced >>> around that close/nil. >>> But ... Is there any hard math theory around how `close()` MUST be >>> implemented in order to have some guarantees about concurrency and >>> consistency? >>> >>> (heavy IMHO warning) >>> Current implementation of close() starts with 2 checks and panics, and >>> the more I think of it, the less I am thrilled about both of them. They >>> both causing me nothing but headache by pretty much requiring 2 channels >>> everywhere code that could be much simpler with just 1 channel and no >>> fluff. Implementing this "fluff" is error prone and I would add it is not a >>> junior dev task, on whom Go seems to be (quite controversially IMHO) is >>> focused on. >>> >>> So... Did anybody ever proposed a second close() variant that returns an >>> error instead of hard panic-ing inside? >>> >>> For example, if I have >>> >>> err := close(c) >>> >>> it will not panic, but if I use just >>> >>> close(c) >>> >>> all bets are off, just like in a current Go code? I think this would be >>> perfectly code-compatible with an "old" code, keeping Go1 compatibility >>> guarantee untouched. >>> >>> Thank you very much, >>> Andrey >>> >>> -- > 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. > 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. For more options, visit https://groups.google.com/d/optout.
