A way to detect closed channel

[Albert Tedja]

So, I just found out that closed channels always yield the zero value. That means, a closed channel inside a select statement seems to always be guaranteed to be executed.

Since closing an already closed channel creates a panic, does this mean then I can do this to make sure that the channel is closed only once?

select {
    case <- closedchan:
    default:
        close(closedchan)
}

Golang playground: https://play.golang.org/p/LSrTh0HC2K

It seems to work. Just want to confirm here before start doing this everywhere in my code.

[Albert Tedja]

Assuming of course, that the channel is only intended to send closed signal to other goroutines, rather than transporting meaningful data.

[Dan Kortschak]

No. The complete select+code blocks is not atomic, so the select may
see that closedchan is not closed, execute the default case, but in the
mean time closedchan has been closed by someone else. Bang!

[Daniel Skinner]

meaning, don't call that select+code block from multiple goroutines. If on the other-hand that block is always called from the same goroutine, then it will do what you want, but that may be a slippery slope depending on what you're writing.

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Albert Tedja]

That makes sense.  If multiple goroutines are calling that select block, one or more could be attempting to close it.

Okay, nevermind then.

[Marvin Stenger]

You might want to use a sync.Once here.
https://golang.org/pkg/sync/#Once

[sheepbao]

func isClose() bool {

    select {

    case <-closeChan:

        return true

    default:

        return false

    }

}

    

在 2017年11月7日星期二 UTC+8上午8:59:51，Albert Tedja写道：

[Dan Kortschak]

This is not a good idea (and is wrong since it does not check the ok
value of the receive operation). As was pointed out previously, this is
only true in the instant that the select is occurring.

[Dave Cheney]

This is not safe. https://play.golang.org/p/ax6fG_ZCE_ 

[roger peppe]

On 7 November 2017 at 00:59, Albert Tedja <nicho...@gmail.com> wrote:
> So, I just found out that closed channels always yield the zero value. That
> means, a closed channel inside a select statement seems to always be
> guaranteed to be executed.
>
> Since closing an already closed channel creates a panic, does this mean then
> I can do this to make sure that the channel is closed only once?
>
>
> select {
> case <- closedchan:
> default:
> close(closedchan)
> }

You can do that if you wrap it in a mutex so that nothing else
can be doing the same thing at the same time. That's
a common workaround for the fact that sometimes you want
to be able to close a signal-only channel (chan struct{}) from
a Close method that might be called multiple times.

Another possibility might be to do this:

func closeChan(c chan struct{}) {
defer func() {
// Catch the panic from closing an already-closed channel.
recover()
}()
close(c)
}

[Steven Hartland]

If you're using it as a signal to trigger only on close and not sending any data, you should use chan struct{}, the reason for this is is that the empty struct consumes zero storage.

Also there is a multi-valued assignment form of the receive operator, which reports whether a received value was sent before the channel was closed.

Dave Cheney's article curious channels is also relate so worth a read.
   
    Regards
    Steve

[Dave Cheney]

gross.

[Daniel Skinner]

Instead of recover, I'd consider simply writing to the channel.

https://play.golang.org/p/ShoadwrwTQ

If it has to be a close, pass in additional state to close only once.

https://play.golang.org/p/pwO3JF60Cr

[Jason E. Aten]

As others pointed out, you need to use a lock if you want to close a channel from multiple, possibly concurrent, code locations. 

Here is an example of how I handle such situations:

https://github.com/glycerine/idem/blob/master/halter.go#L11

Feel free to use that library, or parts of it.  In short, if you want an idempotent close, you have to replace close() with your own Close().

Meta comment: it was, in my view, a poor design decision in Go (not to allow multiple closes of a channel). For backwards compatibility reasons we are stuck with it now.  Its a wart/minor annoyance in the grand scheme of things. Fortunately, the workarounds, while elaborate and slow, are very rarely on hot code paths.

[Jason E. Aten]

Also since nobody else mentioned it, for completeness: the optional second argument to the receive will always tell you if the channel is already closed, if all you are doing is trying to distinguish the zero value from a closed versus unclosed channel.

https://golang.org/ref/spec#Receive_operator

[Christian Surlykke]

This little pattern may also be useful:

ticket := make(chan bool, 1)
ticket <- true
close(ticket)

Now, first read from ticket will yield true, all subsequent reads will yield false.

So any number of go-routines can do this if, but the call to close will happen at most once:

if (<-ticket) {
    close(myChannel)
}

br. Chr.