go version)?go 1.12
yes.
go env)?linux amd64
I added the api reset function.
I hope that the proposal will take effect,because sometimes we need to adjust the time dynamically.
This is not a problem,this is just a suggestion.
Please read the following.thanks.
api:
// Reset duration to reset a ticker.
func (t *Ticker) Reset(d Duration) bool {
if t.r.f == nil {
panic("time: Reset called on uninitialized Ticker")
}
w := when(d)
active := stopTimer(&t.r)
t.r.when = w
t.r.period = int64(d)
startTimer(&t.r)
return active
}
It seems reasonable to be able to change the duration on a ticker.
But the return value from time.Timer.Reset was a mistake and is impossible to use correctly, and this API would provide the same return value. It seems like better options would be to have no return value from Reset and either:
The second seems defensible to me and useful in code that is doing something like:
t := time.NewTicker(d)
for range t.C {
if ... { t.Reset(newD) }
}
In general, if the Reset is happening separate from the channel receive, you'd want to do t.Stop, then synchronize with the receiver so it knows to expect a new duration, then t.Reset. But the pattern above does not need that because the receiver and the Reset caller are the same, and that seems likely to be common.
So I would lean toward option 2. Thoughts?
@rsc
I agree that Reset has no return value,but I don't know what stopTimer returns error under what conditions,at first I just wanted to separate out two apis,like this:
func NewTicker(d Duration) *Ticker {
...
//startTimer(&t.r)
return t
}
func (t *Ticker) StartTicker() {c
startTimer(&t.r)
}
This way developers can control their own startup time,later added api Reset,using like this:
ticker := time.NewTicker(d)
go func() {
for _ = range ticker.C {
...
}
}()
...
...
...
if ... {
ticker.Reset(newD)
}
But this does have a situation where stopTimer returns an error,do you have a better solution?
Given the two options I mentioned above, it seems like "the ticker is not stopped, first stop it and drain any existing value from the channel" is the much less error-prone API. If you don't want that, you can of course stop the ticker yourself first.
With that clarification, this seems like a likely accept.
No change in consensus, so accepted.
Change https://golang.org/cl/217362 mentions this issue: time: add Ticker.Reset
Change https://golang.org/cl/220638 mentions this issue: Revert "time: add Ticker.Reset"
CL reverted due to test failures, so reopening.
Example failure on arm64: https://build.golang.org/log/518de921e4d47fb5130e0f9f969437fdab9d872e
Relevant snippet:
--- FAIL: TestTicker (4.64s)
tick_test.go:74: saw 5 errors
tick_test.go:32: 5 100ms ticks took 967.285125ms, expected [480ms,720ms]
tick_test.go:32: 5 100ms ticks took 866.8515ms, expected [480ms,720ms]
tick_test.go:32: 5 100ms ticks took 895.289792ms, expected [480ms,720ms]
tick_test.go:32: 5 100ms ticks took 901.194458ms, expected [480ms,720ms]
tick_test.go:32: 5 100ms ticks took 1.009654709s, expected [480ms,720ms]
FAIL
FAIL time 8.980s
FAIL
go tool dist: Failed: exit status 1
Change https://golang.org/cl/220424 mentions this issue: time: add Ticker.Reset
Most helpful comment
No change in consensus, so accepted.