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.

Reply via email to