Re: [go-nuts] Re: Check Channel is active or not while Writing as writer Go routine

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

[go-nuts] Re: Check Channel is active or not while Writing as writer Go routine

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

[go-nuts] Re: HTML templates - recommendations to unset ?

On Monday 28 October 2024 at 13:47:38 UTC+1 Marc Coquand wrote: > I was wondering if there are any best practices or tooling to help you > make sure that all variables are set? You can pass an the "missingkey=error" option to the template. See https://pkg.go.dev/html/template#Template.Option. --

Re: [go-nuts] Check Channel is active or not while Writing as writer Go routine

On Thursday 24 October 2024 at 18:42:35 UTC+2 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. I agree with this strongly. I think therere should be an owner of the channel in some way, usually

Re: [go-nuts] Re: Why there is no net.ListenContext?

Hi, I have been watching this proposal proposal: io/v2: add Context parameter to Reader, etc. · Issue #20280 · golang/go . I think they provide some rationale why context is problematic for these things. I think something like net.Listen would over

[go-nuts] Re: Iterator handling error

>On Friday 30 August 2024 at 12:05:33 UTC+2 Christoph Berger wrote: >Opinionated answer: If a container type cannot iterate over its elements without fail, I would refrain from trying to build a standard iterator for this container type. You'd be shoehorning a >iterator that can fail into the ite

Re: [go-nuts] Non-blocking Read from StdoutPipe and StderrPipe

Perhaps you can use a context. It wouldnt be truely nonblocking but maybe it is sufficient to use cancel or deadline. https://cs.opensource.google/go/go/+/refs/tags/go1.23.2:src/os/exec/exec.go;drc=d0146bd85bb6870aa43a498b06ccb473af55cbe3;l=453. -- You received this message because you are s

[go-nuts] Re: good practice or premature optimization

instructions for more bound checks? So the assembly or bytecode will be smaller. On Friday 11 October 2024 at 08:34:00 UTC+2 tapi...@gmail.com wrote: > On Thursday, October 10, 2024 at 11:51:02 AM UTC+8 Nico Braun wrote: > > Hi, recently I became very self aware of potential performance > imp

[go-nuts] good practice or premature optimization

Hi, recently I became very self aware of potential performance implications my code might have. In go there are a few key concepts, like escape analysis and bound checks. If you check the standard library, you can see it was coded with micro optimizations. For example, disabling bound checks

Re: [go-nuts] Re: Map with expiration

I started thinking about the compaction, and if there was a way to prevent stopping the world during cleanup. May be interesting to look how etcd or redis something does it. Could you use a RWMutex for this map, or is this not a good use case? On Wednesday 9 October 2024 at 08:36:34 UTC+2 Def C

[go-nuts] Re: Map with expiration

r 8, 2024 at 9:10:16 PM UTC+2 Nico Braun wrote: > >> Well, you do that already. Except its having 1 goroutine per entry. Maybe >> 1 goroutine for all would be enough. >> >> On Tuesday 8 October 2024 at 21:07:22 UTC+2 Nico Braun wrote: >> >>> Hi, isnt t

[go-nuts] Re: Map with expiration

Well, you do that already. Except its having 1 goroutine per entry. Maybe 1 goroutine for all would be enough. On Tuesday 8 October 2024 at 21:07:22 UTC+2 Nico Braun wrote: > Hi, isnt this kind of inefficient? I think it would be better without > tickers and extra goroutines. You could

[go-nuts] Re: Map with expiration

Hi, isnt this kind of inefficient? I think it would be better without tickers and extra goroutines. You could check if an item is expired when trying to fetch it. And then you do periodic compaction to make sure old stuff is freed up, eventually. On Monday 7 October 2024 at 21:37:53 UTC+2 Alex

[go-nuts] slices and sync pool

Hello, I read this article and it left me confused. Unlocking Go Slice Performance: Navigating sync.Pool for Enhanced Efficiency | by Mike Norgate | Medium . (sorry for payw