https://go.dev/wiki/Go123Timer

"Unstopped timers and tickers that are no longer referenced can be garbage 
collected. Before Go 1.23, unstopped timers could not be garbage collected 
until the timer went off"

On Thursday, 26 February 2026 at 15:07:37 UTC Slawomir Pryczek wrote:

> Hi Everyone. In my code i'm making eg. 8 http requests, in fact i need 
> half of it, but it's good to have these missing ones if i'm able to get it 
> in short timespan. For example having 4 requests in 10 ms is good, 8 
> requests in 9ms is great while waiting for full timeout (eg. 50ms) to just 
> get these missing 4 is counter productive. So it's like "get half of the 
> requests ASAP+5ms or get all in 50ms max"
>
> So i'm implementing a timeout using select / time.After. When i get 4 
> requests i'm just creating another time.After and replace variable with it, 
> attaching code
>
> ----------------------------------------
> total_requests := len(j.id)
> out := make([]httpjob_response, 0, total_requests)
> timeout := time.After(time.Duration(maxTimeMS) * time.Millisecond)
> ....
> should_run := true
> var error_timeout Status = ERR_TIMEOUT
> for i := 0; should_run && i < total_requests; i++ {
>
>   // here we have special support for case where we already got minResult 
> results
>   // so we can wait a little more (eg. 5 ms) to try to get the last 
> result, or just finish
>   if i == minResults {
>     timeout = time.After(time.Duration(5) * time.Millisecond)
>     error_timeout = ERR_SKIPPED // if we can't get this request in time, 
> treat it as skipped as we don't need it
>   }
>
>   select {
>   case v := <-j.ch:
>     out = append(out, v)
>     case <-timeout:
>       append_missing(error_timeout)
>       should_run = false
>     }
>   }
>   append_missing(ERR_SKIPPED)
> ----------------------------------------
>
> Now claude ai is insisting that this time.After (which creates a channel) 
> is getting properly garbage collected. Not sure how, when (as per spec) the 
> channel with pending write should linger indefinitely as long as it isn't 
> read from. Moreover "only the sender should close a channel, and only when 
> it's done sending", during that potential GC this channel will get closed.
>
> If the channel is closed / GC'd with blocking send, how that works. If 
> not, what's some better way of doing that?
>
> "As of Go 1.23, the channel is synchronous (unbuffered, capacity 0)" so if 
> the write occurs before GC, and there is no one to read from the channel, 
> is it still properly collected?
>
>
>
>

-- 
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 [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/golang-nuts/22b72b6e-58a3-4f70-8565-1942eba47487n%40googlegroups.com.

Reply via email to