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.
