Yes thanks for the answer, also found this one however my concern is about GC'ing timers (stopped or unstopped) after they fired and there is nothing on the other side to "receive" the message (there is only writer [with or without a pending write] AND [no reader] )
Would be great if i could just do time.After and never use the result, this case i want to confirm czwartek, 26 lutego 2026 o 17:47:04 UTC+1 Brian Candler napisał(a): > 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/d0dbf293-d87d-4cde-9574-bef2bc2ba4b3n%40googlegroups.com.
