Robert makes an insightful point. You probably don't want to be closing
channels that have actual data conveyed / sent through them in the first
place.
Closing a channel is most often used as a means of broadcasting a state
change, rather than signaling EOF (end of file).
Doing for-range loop over a channel is a cute teaching example, but it
should be banned because it misleads beginners.
They end up thinking they can write for-range over channels in production
code, which is almost always a mistake,
because it prevents a clean shutdown being acheived; that where all
goroutines have stopped.
So a practical design heuristic might be, only close channels that are chan
struct{}, in other words, that are never going to convey data, and only
going to broadcast a state change (typically that a task or job has
completed, and one or more other goroutines want to know about that).
There are some good resources for reading about these patterns. The best
I've seen are
these old talks from 10+ years ago. And read the Go language spec about
channels and select. It is readable, unlike most specs.
https://go.dev/ref/spec#Select_statements
https://github.com/glycerine/thinkgo/blob/master/vendor/John_Graham-Cumming_A_Channel_Compendium.pdf
https://github.com/glycerine/thinkgo/blob/master/vendor/GoCourseDay3.pdf
On Thursday, October 24, 2024 at 5:42:35 PM UTC+1 robert engels wrote:
> In my experience, the OP’s issue points to a code structure problem and
> not having a deterministic lifecycle for the channels.
>
> You rarely need specific/additional state to track this. You can look at
> github.com/robaho/go-trader which uses multiple channels - it doesn’t
> even close them (it relies on controlling the reader/writer lifecycle based
> on other higher level state - once those are gone, the channels are
> collected).
>
> On Oct 24, 2024, at 10:58 AM, Jason E. Aten <j.e....@gmail.com> wrote:
>
> Usually you just set to nil any channel you do not want to use. You do
> also have to
> typically keep track of whether a channel is closed already or not in a
> separate
> bool variable that is protected by a mutex. But anyway, a nil chan can
> still be used in a select. But if nil, then select {} will ignore it.
>
> Remember that channels are reference types (pointers inside; like maps) so
> setting your local
> copy of a chan to nil will not effect the copy of the same chan elsewhere.
>
> You can even call a function within the select case that returns nil or
> live channel depending
> on an arbitrary condition you decide on. I call this "conditional send" or
> "conditional receive".
> It is a useful pattern.
>
> also useful:
> import "github.com/glycerine/idem" // just FYI, see NewHalter() for
> handling shutdown and channel wrappers that can can have Close() called
> many times. Useful for cleanup/shutdown sequences that have inherent
> non-determinism/multipath races.
>
> example of conditional send/receive:
>
> regularChan := make(chan int)
>
> select {
> case: myInt := <- conditionalReceive(regularChan):
> ...
> case conditionalSend(regularChan) <- 9:
> ...
> }
>
> func conditionalReceive(regularChan chan int) chan int {
> if youWantToReceiveNow {
> return regularChan
> }
> return nil
> }
> func conditionalSend(regularChan chan int) chan int {
> if youWantToSendNow {
> return regularChan
> }
> return nil
> }
>
>
> On Thursday, October 24, 2024 at 2:08:33 PM UTC+1 Aniket Pandey wrote:
>
>> Has anyone have implemented the logic in order to check if the channel is
>> active if the channel is active then only will write the data .if yes how
>> to do so? As i am getting the Following error: *panic: **send on closed
>> channel*
>>
>> As a writer go routine i want to only write data to active channels
>> ..
>
>
> --
> 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.
> To view this discussion visit
> https://groups.google.com/d/msgid/golang-nuts/db2345ea-b8e6-4a98-8280-a883cb09cdfen%40googlegroups.com
>
> <https://groups.google.com/d/msgid/golang-nuts/db2345ea-b8e6-4a98-8280-a883cb09cdfen%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
>
--
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.
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/00c18cf9-4a33-42c2-ab58-3b0ded1f1cc7n%40googlegroups.com.
