On Wed, Apr 1, 2020 at 11:05 AM Neil Schellenberger <neilschellenber...@gmail.com> wrote: > > I am almost certainly overthinking this or in some other way "doing it > wrong"--so please (dis)abuse me. > > The Timer.Reset() documentation reads (in part) "Reset should be invoked only > on stopped or expired timers with drained channels." > > Am I correct in understanding that "should" in that sentence means that if > neither condition holds then calling Reset() nevertheless still results in > legal, well defined behaviour? I.e. "should" (lest you e.g. unintentionally > race) not "must" (lest you e.g. hang). > > From inspection of the implementation it appears that the only real > consequence of the inherent race is that it might result in either the "old" > or "new" expiry being delivered on the next receive. And even if the "old" > expiry is still pending in the (buffered, size one) channel when the runtime > attempts to deliver the "new" expiry, the "new" expiry is simply dropped > rather than causing any type of deadlock or similar grief to the runtime > (i.e. per sendTime(), literally the same callback as for time.Ticker). > > I apologise in advance for further belabouring this hoary chestnut ([1][2][3] > et multa al. e.g. in StackExchange, Reddit etc.) but I've gotten myself > thoroughly confused as to what is guaranteed by the specification. Taken > precisely as written, the admonishments are simply cautions--particularly > when read in conjunction with the Timer.Stop() documentation (which uses less > proscriptive lanaguage). But they are so lengthy that they left me with the > nagging sense that there might be something more subtle and dire lurking > behind that I was failing to grasp. (I.e. no matter how carefully written > the documentation some b*gger--me--will always misunderstand, misinterpret, > or otherwise misconstrue it.)
You are correct: calling Reset on a timer that is neither stopped nor expired will not cause any sort of deadlock, it will just lead to a race for your program. The issue is simply that the only point of a timer is for it to send some value on a channel. If you call Reset on a timer that is neither stopped nor expired, then you have no idea whether the value sent on the channel is from the old timer expiration or the new timer expiration. If it's from the old timer expiration, you will eventually get another one from the new timer expiration, but you don't know whether that will happen or not. If your program doesn't care about that, then it's fine to go ahead can call Reset on an active timer. But it's hard to understand why a program wouldn't care. Unless, I suppose, the timers are far in the future and you can neglect the case of a goroutine pausing for that long. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUD-VDOoQdEnS0KxH4GyO3n2-%2Bs9Pr5n-wEOBwqG7b1GQ%40mail.gmail.com.
