runtime: avoid monotonic time zero on systems with low-res timers

Otherwise low-res timers cause problems at call sites that expect to
be able to use 0 as meaning "no time set" and therefore expect that
nanotime never returns 0 itself. For example, sched.lastpoll == 0
means no last poll.

Fixes #22394.

Change-Id: Iea28acfddfff6f46bc90f041ec173e0fea591285
Reviewed-on: https://go-review.googlesource.com/73410
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

diff --git a/src/runtime/proc.go b/src/runtime/proc.go
index 48ce7d62488df954499aa7019f72fd401a22b54d..af9b33886c0624ace89d6a0e2dbedb4c198e9317 100644 (file)
--- a/src/runtime/proc.go
+++ b/src/runtime/proc.go
@@ -142,6 +142,9 @@ func main() {
        }
 
        runtime_init() // must be before defer
+       if nanotime() == 0 {
+               throw("nanotime returning zero")
+       }
 
        // Defer unlock so that runtime.Goexit during init does the unlock too.
        needUnlock := true

diff --git a/src/runtime/time.go b/src/runtime/time.go
index 0e1763e0cd0e698912a7b6ba96239b009ec34921..6c349c8461bc7efc8304cc889228bba980ed5673 100644 (file)
--- a/src/runtime/time.go
+++ b/src/runtime/time.go
@@ -395,4 +395,10 @@ func time_runtimeNano() int64 {
        return nanotime()
 }
 
-var startNano int64 = nanotime()
+// Monotonic times are reported as offsets from startNano.
+// We initialize startNano to nanotime() - 1 so that on systems where
+// monotonic time resolution is fairly low (e.g. Windows 2008
+// which appears to have a default resolution of 15ms),
+// we avoid ever reporting a nanotime of 0.
+// (Callers may want to use 0 as "time not set".)
+var startNano int64 = nanotime() - 1