runtime: use monotonic time on netbsd

[gopherbot]

by gmale120:

import (

    "fmt"

    "time"

)


func main() {

    go aa()

    var str string

    fmt.Scan(&str)

}

func aa() {

    var t time.Time

    for {

        x := time.After(5 * time.Second)

        t = <-x

        fmt.Println(t)

    }


}
如果我改变了系统的当前时间，然后这个就失效了。
我先把当前时间提前一小时，看有没有输入。等了很久，没有输出。
然后再改回来，还是没有输出。
就算你出问题，也别死在那里呀
不准没关系。失效问题就大了
Automatic translation 

If I change the system's current time, then this failure. 

I change the system's time befor current time. Wait for a long time, no output. 

And then change back,and wait a moment,still no output. 

There, even when you are out of the question, don't also died 

No it doesn't matter. Failure problem is big

[rsc]

Comment 1:

What operating system are you using?
This may be a problem in the way we are using the system timers but it may also just be
a problem with the OS.

Labels changed: added priority-later, suggested, removed priority-triage.

Status changed to Accepted.

[alexbrainman]

Comment 2:

The output surely stops (on both linux and windows) if I change my system time to minute
late. :-)
Alex

[rsc]

Comment 3:

Status changed to TimedOut.

[alexbrainman]

Comment 4:

Russ, why did you set status to "TimedOut"? I think there is a problem here. It just a
question whether we want / can fix it. Or if it is important enough. Isn't it?
Alex

[rsc]

Comment 5:

Can you post an example program and explain how to demonstrate the problem? I closed the
issue because I don't understand the report.

Status changed to WaitingForReply.

[alexbrainman]

Comment 6:

Run this program
package main
import (
        "fmt"
        "time"
)
func main() {
        for {
                fmt.Println(<-time.After(time.Second))
        }
}
and watch it outputs new line to stdout once every second. While the program runs,
change your system time to 1 minute back (whatever your current time is minus 1 minute).
I use "date" command on linux for that. Watch running program output stops. Should it?
Shouldn't it?
Alex

[karalabe]

Comment 7:

Hi,
  Here's a go-nuts thread about this exact same issue that hit me in the face yesterday: https://groups.google.com/forum/#!topic/golang-nuts/mUOr4UvsYOY
  The issue is that any pending ticker will get ruined during an OS time update. E.g. as in the above examples, you start a ticker for 1 secs, set back the OS timer a few hours, and the ticker will never fire (at least not until the OS time reaches the original ticker time).
  And to give you two real-world examples when this happens: daylight saving (OS updates the date, all tickers pause for an hour). The other is what I got hit with: you boot up the OS, automatically start a Go program, and after a while the clock syncs up and all tickers within the program get corrupted (and this is what actually happens on Google Compute Engine VMs).
Cheers,
  Peter

[dvyukov]

Comment 8:

The issues in #7 looks WorksAsExpected/Unfortunate, because time operates with real time
FWIW. Which is, in my opinion, a design bug, but it is the way it is. This should be
solved as part of a more serious changes, there is a discussion on goleng-dev about
monotonic clocks.
Is it the case that when you set time a minute back, timers stop ticking at all (no
ticks after 5 minutes)? This would be a bug.

[alexbrainman]

Comment 9:

> Is it the case that when you set time a minute back, timers stop ticking at all (no
ticks after 5 minutes)?
No, it is not the case. Timer starts ticking again once new time catchers up with old
time. The program is stuck for 1 minute and then it continues on as if nothing happend.
Alex

[rsc]

Comment 10:

There's no magic bullet here. If we use wall time we get weirdness like this when the
computer's reported wall time jumps around. If we use some other kind of monotonic "time
since boot" time, then things like:
t := time.Now()
time.Sleep(10*time.Minute)
fmt.Println(time.Since(t))
can literally print any value, something arbitrarily far from 10 minutes, even a
negative number.
I don't think there's anything we can do here that is significantly better than what we
have.

Status changed to Unfortunate.

[jayschwa]

Comment 11:

This same issue (wall clock vs monotonic clock) caused real problems at my previous
embedded systems job (using C, not Go :-). I think it's a serious issue and should not
be taken lightly.
Currently, it looks like nanotime() and now() are aliases to each other. My armchair
layman's thought is to keep now() functionally the same (i.e. it returns wall time) and
have nanotime() use a monotonic clock instead. I'd try it myself except that the
relevant bits are in assembly and I haven't wrapped my head around it yet.
Considering two core devs have called this issue "Unfortunate", I must be missing
something though.

[dvyukov]

Comment 12:

I meant that is's more WorksAsExpected, because it's the current documented semantics,
we can not just change it.
However, there are things we can do about it. If you want to blink a window every
second, check email every minute, or timeout idle tcp connection after 5 min, then you
pretty much do not care about the output of:
t := time.Now()
time.Sleep(10*time.Minute)
fmt.Println(time.Since(t))
You just want timers against monotonic time.
In the end, the following code can work perfectly reasonably (well, hibernation aside):
t := time.MonoNow()
time.MonoSleep(10*time.Minute)
fmt.Println(time.MonoSince(t))
Currently we do strange wtfs like timing out tcp connections based on real time...

[rsc]

Comment 13:

It may be possible to make all the relative APIs - After, Sleep, Tick,
Ticker, and Timer - use durations against 'monotonic time'. The package net
timeouts could do the same internally. However, neither will happen for Go
1.2.
The real WTF here is that there are still systems that cannot keep accurate
time and have giant backward or forward time jumps in their real time. Come
on, guys. It's 2013.

Labels changed: added go1.3, removed go1.2maybe.

Status changed to Thinking.

[dvyukov]

Comment 14:

> The real WTF here is that there are still systems that cannot keep accurate time and
have giant backward or forward time jumps in their real time.
This is not an issue. It is the same on good OSes as well.
If you came from server land, you can think that real time==monotonic time. But this is
absolutely not true in desktop environment (and there are still bad administrators and
so on). On the golang-dev thread I've described some examples when real time changes
+/-24h several times a day. For some period of time I was periodically changing real
time on my desktop +/-3 *years* to trick some software.
Do NOT think of real time as of something related to monotonic time whatever OS you
have. For the purpose of correctness, real time must be considered as random number
generator.
This is expected that if you want to schedule some activity every (realtime) midnight,
it will behave weirdly in such environment (and there is nothing we can do with it).
But it's a failure on our side, if all Go software suddenly crashes/timeouts/hangs when
a user changes real time to +/-12h. And this is what happens now (all network
connections suddenly timeout or never timeout; time.Ticker(time.Second) stops ticking,
etc).

[jayschwa]

Comment 15:

> it's the current documented semantics, we can not just change it.
Where is it documented? I do not see anything in the documentation for Duration (or the
functions that use it) that indicates it is used as a delta for wall time. If anything,
I think changing Duration-related functions to use a monotonic clock would make it more
accurate and less surprising with its current documentation.
> The real WTF here is that there are still systems that cannot keep accurate
time and have giant backward or forward time jumps in their real time.
Not all devices have the luxury of saving the time and asking the Internet. At my
previous job, I worked on an embedded system that did not save time across power cycles
because it was small and didn't have a battery. An external source would eventually push
a time to my device sometime after boot. The time updates would not necessarily come
right away, and sometimes the time would jump around multiple times (and by large
magnitudes) depending on the kind of testing the systems guys were doing. The software
had to use monotonic clocks in order to be robust and not break during wall time changes.