On Wed, Jan 25, 2017 at 10:30 AM, Tim Hockin <thoc...@google.com> wrote: > Thanks! That makes sense. Does it make sense to update the docs to > show the "select-with-default" mode of draining the channel instead?
I guess I don't think so, as there is still a potential race with the other receive. I mean, we can make the docs arbitrarily complicated, but at some point it should be on the wiki or something. Ian > 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.
