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/1cf2ca46-8bda-4751-b730-c01ef2ce774cn%40googlegroups.com.

Reply via email to