Thank you very much for confirming that, Ian!
FWIW the scenario is very roughly along the lines of a "best effort
re-configurable" timeout for a work loop:
timeout := <-timeoutConfigC
timer := time.NewTimer(timeout)
defer timer.Stop()
for {
select {
case timeout = <-timeoutConfigC:
timer.Reset(timeout) // if the user's new preference "just misses"
this interval, oh well, next time then
case <-timer.C:
handleTimeout()
timer.Reset(timeout)
case work := <-workC:
if done := do(work); done {
return
}
}
}
The actual use case is a protocol state machine with various user tunable
intervals. It's fine if a new value doesn't get "applied" until the "next
time around".
Obviously there are plenty of other ways to handle this, but it got me
wondering if I understood "Timer.Reset()" properly or not. And/or I may be
using an anti-pattern. Do please let me know if I am :-)
--
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 on the web visit
https://groups.google.com/d/msgid/golang-nuts/66358963-9cc4-400d-ab8f-ab6dd1ee5184%40googlegroups.com.
