On Thursday 24 October 2024 at 22:37:27 UTC+5:30 Jason E. Aten wrote:
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.
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).
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
..
