Nice article. I think it over complicates the situation though and may lead to confusion. Some situations lead naturally to a go routine per request (web server processing) - with a fixed lifetime - others lead to a fixed count of go routines (like services) - permanence. Using ephemeral channels i
On Thursday, October 31, 2024 at 10:24:23 PM UTC+8 Nico Braun wrote:
I think not closing the channel has the side effect, of making it easier
to leak goroutines. If your memory is growing, its likely that there is
still a receiver who didn't realize there is nothing more to receive.
That is one
Hi All ,
while performing trial and error i just implemented an idea of not closing
the channel in my go-lang code , due to which my server memory was going
high , sharing it just FYI
On Thursday 31 October 2024 at 11:27:09 UTC+5:30 Nico Braun wrote:
> On Tuesday 29 October 2024 at 11:31:19 U
I think not closing the channel has the side effect, of making it easier
to leak goroutines. If your memory is growing, its likely that there is
still a receiver who didn't realize there is nothing more to receive.
That is one thing closing a channel can do and oftentimes does, i.e.
when ranging
On Thu, Oct 31, 2024 at 5:29 AM 'Aniket Pandey' via golang-nuts
wrote:
>
> while performing trial and error i just implemented an idea of not closing
> the channel in my go-lang code , due to which my server memory was going
> high , sharing it just FYI
I don't know what happened in your progr
On Tuesday 29 October 2024 at 11:31:19 UTC+1 tapi...@gmail.com wrote:
> https://github.com/golang/go/issues/21985
> https://github.com/golang/go/issues/28017
>
> Personally, I think this is an interesting idea.
Hi, thanks for sharing. I never knew you don't have to close channels,
see: https://git
https://github.com/golang/go/issues/21985
https://github.com/golang/go/issues/28017
Personally, I think this is an interesting idea.
On Thursday, October 24, 2024 at 9:08:33 PM UTC+8 Aniket Pandey wrote:
> Has anyone have implemented the logic in order to check if the channel is
> active if th
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 ig
