Hi Aniket - you probably have a race and per Robert, should restructure not to close the channel ever. We can help you more directly if you would kindly post a playground code example that illustrates the essentials of what you are doing.
See https://go.dev/play/ then press Share and reply here with the link to your example. On Friday, October 25, 2024 at 1:57:58 PM UTC+1 Aniket Pandey wrote: > Thanks for the ideas guys !! > but in my case i have constant running process irrespective number of > writes as my writer channel won't stop sending data directly as it has only > check if the client Active and that is made false once the Socket Reader > function exits and after that i close the channel where in somehow the > Active(bool) tag is not in sync with other go routines which is a reference > variable. > > 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. >> 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/fd912c03-ee8e-4521-aab3-1c7358a2d135n%40googlegroups.com.