Hello.
I apologize if my previous mail was cut unexpectedly short. My e-mail client
did something that I do not completely understand.
ISTM that there are no guarantees about the behavior of that program at all.
Access to c from niller and closer is not synchronized, so it's not really
possible to reason about the behavior of the program.
Superficially, perhaps synchronizing between close(c) and c = nil could fix
the data race and allow you to reason about the behavior of the program, but
it doesn't feel like that is the real solution. I would look for a way to
establish a stronger ownership model of the channel in my program, such that
it is obvious which goroutine owns it, closes it, sets it to nil, etc.
On 3/13/19 7:40 AM, 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
>
--
Andrei Tudor Călin
--
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.
