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 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://github.com/golang/go/issues/27544#issuecomment-419515859. > Been using go for several years at this point, lol. This changes a lot, > in my opinion. > > Many times, each sender can just stop sending the channel and have it > get garbage collected, when all are done. It may be even the preferred, > way. Closing the channel more more like a broadcast and not a resource > freeing operation. > > Now this sentence makes a lot more sense to me: > > https://pkg.go.dev/sync#Cond wrote: > > For many simple use cases, users will be better off using channels > > than a Cond (Broadcast corresponds to closing a channel, and Signal > > corresponds to sending on a channel). > > After learning that you don't have to close channels, I think more like > rob pike says it in the github comment below. > > https://github.com/golang/go/issues/21985#issuecomment-331622588: > > If a program sends on a closed channel, it's not managing resources > > correctly. You could argue that your proposal makes it easier to do > > that, but I would counter that it makes it too easy to construct poor > > concurrent structures. > -- .. -- 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/5c1581ac-6c81-4267-8af2-e56a2d363a38n%40googlegroups.com.
