Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
time: time.After(math.MaxInt64) kills all time.After() instances #4903
Running this on go tip produces no output. I realise putting MaxInt64 into time.After is not exactly expected usage, but it happened and I thought I'd report it. What steps will reproduce the problem? http://play.golang.org/p/k2uA7Xo22u What is the expected output? I would expect the second goroutine to print a "." every second. What do you see instead? Nothing. Both selects block. Which operating system are you using? Darwin cavern.local 12.2.1 Darwin Kernel Version 12.2.1: Thu Oct 18 12:13:47 PDT 2012; root:xnu-2050.20.9~1/RELEASE_X86_64 x86_64 Which version are you using? (run 'go version') go version default darwin/amd64 33d3e7bbd3ef tip Please provide any additional information below.
When creating a timer, the duration is added to the current time in nanoseconds and stored in an int64. This overflows for long durations, storing a negative "when" time. In package runtime, the pending timers are stored in a queue that is sorted by "when". The timerproc goroutine periodically checks this queue to see if any new events need to be fired. The way it checks is by iterating through the timers and computing delta = t->when - now; and stopping if delta >= 0. If that loop exits with delta < 0, it's assumed that there's no work to do and the goroutine is parked. I think one important fix is to make timerproc use a separate flag to mean "didn't find anything to do." instead of using a negative delta. The other important fix is to prevent "when" from overflowing maxint64 in the first place. I don't think Sleep and After should panic on overly large durations. Probably it should just truncate when to maxint64 in those cases. I don't think this matters; nobody will be sleeping in go programs past the year 2262. Or, if they are, our descendants can revisit this a century before then.