Slawomir Pryczek wrote: 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 short answer: Using Go 1.23 or greater, yes, you will be fine. longer answer: This is just garbage collection. If you overwrite "timeout", the old timer channel that was referenced now has no more references, and will be garbage collected, full stop. It does not matter what its fired or non-fired state is. more than you want to know probably: Delivery on the one-way <-chan time.Time channel of a timer is done here in the time.sendTime() function: https://github.com/golang/go/blob/master/src/time/sleep.go#L188 Notice the default: clause in that select: the runtime will never wait on you; func sendTime(c any, seq uintptr, delta int64) { // delta is how long ago the channel send was supposed to happen. // The current time can be arbitrarily far into the future, because the runtime // can delay a sendTime call until a goroutine tries to receive from // the channel. Subtract delta to go back to the old time that we // used to send. select { case c.(chan Time) <- Now().Add(Duration(-delta)): default: } } and >= Go 1.23, the timer channel is unbuffered. I'm told the runtime does some "magic" to only even try to delivery timers when they are ready to fire too... but you'd have to confirm that as I don't remember the source of that impression. -- 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/73f357a6-c934-42f5-bb94-2ac4250f4385n%40googlegroups.com.
