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.
