mirror of
https://github.com/tailscale/tailscale.git
synced 2024-12-01 14:05:39 +00:00
1a78f240b5
In almost every single use of Clock, there is a default behavior we want to use when the interface is nil, which is to use the the standard time package. The Clock interface exists only for testing, and so tests that care about mocking time can adequately plumb the the Clock down the stack and through various data structures. However, the problem with Clock is that there are many situations where we really don't care about mocking time (e.g., measuring execution time for a log message), where making sure that Clock is non-nil is not worth the burden. In fact, in a recent refactoring, the biggest pain point was dealing with nil-interface panics when calling tstime.Clock methods where mocking time wasn't even needed for the relevant tests. This required wasted time carefully reviewing the code to make sure that tstime.Clock was always populated, and even then we're not statically guaranteed to avoid a nil panic. Ideally, what we want are default methods on Go interfaces, but such a language construct does not exist. However, we can emulate that behavior by declaring a concrete type that embeds the interface. If the underlying interface value is nil, it provides some default behavior (i.e., use StdClock). This provides us a nice balance of two goals: * We can plumb tstime.DefaultClock in all relevant places for use with mocking time in the tests that care. * For all other logic that don't care about, we never need to worry about whether tstime.DefaultClock is nil or not. This is especially relevant in production code where we don't want to panic. Longer-term, we may want to perform a large-scale change where we rename Clock to ClockInterface and rename DefaultClock to just Clock. Updates #cleanup Signed-off-by: Joe Tsai <joetsai@digital-static.net> |
||
|---|---|---|
| .. | ||
| mono | ||
| rate | ||
| jitter_test.go | ||
| jitter.go | ||
| tstime_test.go | ||
| tstime.go | ||