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 is what leads to the closing situation/complexity. 

A redesign without ephemeral channels leads to more readily understood code through less complexity. 

If you find yourself using ephemeral channels or needing to close channels at all a redesign may help. 

On Nov 2, 2024, at 1:07 PM, tapi...@gmail.com <tapir....@gmail.com> wrote:



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 thing closing a channel can do and oftentimes does, i.e.
when ranging over channels.

So when not closing channels, one needs another way to signal that all
references to that channel should be released, so the garbage collector
can collect it.

True: https://go101.org/article/channel-closing.html
 

I never thought about it much but it makes sense that closing a channel,
does not free resources. Because you can still receive remaining values
from a closed channel and the zero value afterwards. So it must be
garbage collected, not matter what.

I also missed the earlier posts by Robert and Jason, who already pointed
this out. I really wish someone had told me this earlier. Although it
has an extra disclaimer on the tour. So, my bad.

https://go.dev/tour/concurrency/4
> Another note: Channels aren't like files; you don't usually need to
> close them. Closing is only necessary when the receiver must be told
> there are no more values coming, such as to terminate a range loop.

--
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/fa59f127-c624-47c0-96bb-60a8323d8372n%40googlegroups.com.

--
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/0255FC44-C38A-41B7-B4A2-8409B1C509F4%40ix.netcom.com.

Reply via email to