runtime: select should ignore closed channels

[nigeltao]

This program panics:

package main

import (
    "fmt"
)

func main() {
    c := make(chan int, 10)
    close(c)
    d := make(chan int, 10)
    for i := 0; i < 10; i++ {
        fmt.Println(i)
        select {
        case c <- 0:
        case d <- 0:
        }
    }
    fmt.Println("OK")
}

because c is still selectable even when closed. This seems consistent with the spec, but I think that the spec and the runtime should change.

[bradfitz]

Proposal process?

[nigeltao]

Yeah probably, but I'll wait until the tree opens for 1.6. In the meantime, I wanted to write this down before I forgot, so I filed an old-fashioned issue.

[adg]

There's not much of an argument here, so I suppose it's no surprise that I'm not convinced.

Select ignores cases that contain sends or recevies on a nil channel, which is consistent with just a stand-alone send or receive on a nil channel (outside the context of a select) blocking indefinitely.

If stand-alone sends to closed channels should panic, then they should panic in select too.

[bradfitz]

Also need to consider whether this would be abused by people writing (or encouraging people to write) racy code, where it's unclear which goroutine is the closer.

[rsc]

Closing the channel is a send-like communication from the senders to the receivers that there will be no more sends. If a sender later tries to send on the channel, then the goroutine who did the close is clearly confused. That merits a panic, whether it is part of a select or an ordinary operation.

The fact that close is (like ordinary sends) a communication from sender to receiver is fundamental to its operation. It comes up repeatedly that people want to use close as a reverse signal from receivers to senders to say "stop sending to me". That is not what it means. It would break the unidirectionality of channels. And at least nine times out of ten the people who want to do this have not completely thought through the implications of this kind of cancellation mechanism. There almost always need to be two steps in a cancellation: a request for the cancellation and an acknowledgement that work has in fact stopped. Close can serve as the latter; it cannot serve as both, and we make it as hard as possible for people to do that accidentally.

This insistence that close is a sender -> receiver communication and not the reverse is also the reason why you cannot close a receive-only channel.

The issue report seems to suggest making an exception to the panic only for select, not for ordinary sends. In the run up to Go 1, we actively worked to make select { case X: } as close to plain 'X' as possible, for all communication operations X. I would not break that lightly. (The only exception involves order of evaluation in case Y = <-Z; in select, the evaluation of Z happens first. See http://play.golang.org/p/HppmwsO0QO)

Anyway, those are the reasons for why Go is what it is today. What are the reasons for changing it? They are conspicuously missing from the initial issue report.

[nigeltao]

Yeah, the more I think about it, the more the current behavior seems correct.

As for the motivation, I had a stream of events (a chan event), from a source that can eventually close the channel. Separately, I want to occasionally inject other events into that channel, without panic'ing with a send-on-close. I was hoping to do that via select, but I'll figure out another way instead.