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.
