Better to have a documented race than a potential hang, though, yeah? If it delivers and then I Stop(), drain, Reset(), I might lose the race, have the channel read by the concurrent receiver, and and just block here. Or am I missing some other nuance here?
On Wed, Jan 25, 2017 at 11:21 AM, Ian Lance Taylor <i...@golang.org> wrote: > 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.
