Thanks! That makes sense. Does it make sense to update the docs to show the "select-with-default" mode of draining the channel instead?
On Wed, Jan 25, 2017 at 10:20 AM, Ian Lance Taylor <i...@golang.org> wrote: > On Wed, Jan 25, 2017 at 9:34 AM, 'Tim Hockin' via golang-nuts > <golang-nuts@googlegroups.com> wrote: >> I'm not convinced that the docs quite cover the case I am looking, so >> I am posting here. >> >> https://golang.org/pkg/time/#Timer.Reset says "This should not be done >> concurrent to other receives from the Timer's channel" but it's not >> clear what the repercussions are. >> >> In our case, I have a function to be run periodically, on a timer, but >> it can be run manually too. When run manually, I want to push the >> timer out (restart the period). >> >> I have a goroutine doing: >> >> ``` >> for { >> select { >> case <-stop: >> pr.stop() >> return >> case <-timer.C: >> run() >> } >> } >> ``` >> >> deep inside run(), we have: >> >> ``` >> timer.Stop() >> timer.Reset(period) >> ``` >> >> I understand that I could lose the race and deliver on timer.C _just >> before_ this runs, and that is fine. What I am seeking to know is >> whether this is considered "safe"? The receive is running >> concurrently to the Reset(). Will this cause problems inside Timer, >> beyond the potential "extra" delivery? Do I need to break the loop >> and stop receiving on it while the Reset() happens? > > The sentence "This should not be done concurrent to other receives > from the Timer's channel." is intended to apply to the description of > how to use t.Stop safely. It's there because if you use the code > fragment described there and there is a concurrent receive, you don't > know which channel receive will succeed. In other words, the channel > receive in the code fragment might hang. > > It is safe to use Reset as you describe, as long as you understand > that the timer may expire, and send a value to the channel, as you > call Stop and Reset. If you don't care about that--if an extra value > sent to the channel doesn't matter--then your code is fine. > > Ian -- 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. For more options, visit https://groups.google.com/d/optout.
