2011-08-26 13:15:23 -06:00
|
|
|
// Copyright 2011 The Go Authors. All rights reserved.
|
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
|
|
|
package time
|
|
|
|
|
|
|
|
func init() {
|
|
|
|
// force US/Pacific for time zone tests
|
2013-01-14 15:09:42 -07:00
|
|
|
ForceUSPacificForTesting()
|
2011-08-26 13:15:23 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
var Interrupt = interrupt
|
2011-12-07 12:47:25 -07:00
|
|
|
var DaysIn = daysIn
|
2013-09-06 13:47:39 -06:00
|
|
|
|
2014-09-04 00:04:04 -06:00
|
|
|
func empty(arg interface{}, seq uintptr) {}
|
2013-09-06 13:47:39 -06:00
|
|
|
|
|
|
|
// Test that a runtimeTimer with a duration so large it overflows
|
|
|
|
// does not cause other timers to hang.
|
|
|
|
//
|
|
|
|
// This test has to be in internal_test.go since it fiddles with
|
|
|
|
// unexported data structures.
|
2014-06-12 12:44:55 -06:00
|
|
|
func CheckRuntimeTimerOverflow() {
|
2013-09-06 13:47:39 -06:00
|
|
|
// We manually create a runtimeTimer to bypass the overflow
|
|
|
|
// detection logic in NewTimer: we're testing the underlying
|
|
|
|
// runtime.addtimer function.
|
|
|
|
r := &runtimeTimer{
|
runtime: use monotonic clock for timers (linux/386, linux/amd64)
This lays the groundwork for making Go robust when the system's
calendar time jumps around. All input values to the runtimeTimer
struct now use the runtime clock as a common reference point.
This affects net.Conn.Set[Read|Write]Deadline(), time.Sleep(),
time.Timer, etc. Under normal conditions, behavior is unchanged.
Each platform and architecture's implementation of runtime·nanotime()
should be modified to use a monotonic system clock when possible.
Platforms/architectures modified and tested with monotonic clock:
linux/x86 - clock_gettime(CLOCK_MONOTONIC)
Update #6007
LGTM=dvyukov, rsc
R=golang-codereviews, dvyukov, alex.brainman, stephen.gutekanst, dave, rsc, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/53010043
2014-02-24 08:57:46 -07:00
|
|
|
when: runtimeNano() + (1<<63 - 1),
|
2013-09-06 13:47:39 -06:00
|
|
|
f: empty,
|
|
|
|
arg: nil,
|
|
|
|
}
|
|
|
|
startTimer(r)
|
|
|
|
|
2014-06-12 12:44:55 -06:00
|
|
|
// Start a goroutine that should send on t.C right away.
|
2013-09-06 13:47:39 -06:00
|
|
|
t := NewTimer(1)
|
|
|
|
|
|
|
|
defer func() {
|
|
|
|
// Subsequent tests won't work correctly if we don't stop the
|
|
|
|
// overflow timer and kick the timer proc back into service.
|
|
|
|
//
|
|
|
|
// The timer proc is now sleeping and can only be awoken by
|
|
|
|
// adding a timer to the *beginning* of the heap. We can't
|
|
|
|
// wake it up by calling NewTimer since other tests may have
|
|
|
|
// left timers running that should have expired before ours.
|
|
|
|
// Instead we zero the overflow timer duration and start it
|
|
|
|
// once more.
|
|
|
|
stopTimer(r)
|
|
|
|
t.Stop()
|
|
|
|
r.when = 0
|
|
|
|
startTimer(r)
|
|
|
|
}()
|
|
|
|
|
2014-06-12 12:44:55 -06:00
|
|
|
// If the test fails, we will hang here until the timeout in the testing package
|
|
|
|
// fires, which is 10 minutes. It would be nice to catch the problem sooner,
|
|
|
|
// but there is no reliable way to guarantee that timerproc schedules without
|
|
|
|
// doing something involving timerproc itself. Previous failed attempts have
|
|
|
|
// tried calling runtime.Gosched and runtime.GC, but neither is reliable.
|
|
|
|
// So we fall back to hope: We hope we don't hang here.
|
|
|
|
<-t.C
|
2013-09-06 13:47:39 -06:00
|
|
|
}
|