www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - MonoTime longevity

reply Tanel =?UTF-8?B?VGFnYXbDpGxp?= <tanel58 hotmail.com> writes:
I discovered something potentially troublesome in druntime.
Namely, applications that use MonoTime will break if run 18 hours 
after booting, according to a short program I wrote.

Here's my code:

```
import core.time : MonoTime;
auto mt = MonoTime.currTime;
import std.stdio : writeln;
writeln(mt.ticks / mt.ticksPerSecond / 60 / 60); // prints 18 
(hours) shortly after boot
```

`mt.ticksPerSecond` is `1_000_000_000` on my system.
I really hope I'm doing something wrong.
Dec 22 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/22/15 2:48 PM, Tanel Tagaväli wrote:

 I discovered something potentially troublesome in druntime.
 Namely, applications that use MonoTime will break if run 18 hours after
 booting, according to a short program I wrote.

 Here's my code:

 ```
 import core.time : MonoTime;
 auto mt = MonoTime.currTime;
 import std.stdio : writeln;
 writeln(mt.ticks / mt.ticksPerSecond / 60 / 60); // prints 18 (hours)
 shortly after boot
 ```

 `mt.ticksPerSecond` is `1_000_000_000` on my system.
 I really hope I'm doing something wrong.


MonoTime uses whatever precision is given to it by the OS. So if on your 
OS, ticksPerSecond is 1e9, then your OS clock wraps at 18 hours as well.

In a recent version of D, MonoTime was changed to support multiple 
clocks. Use MonoTimeImpl!SomeClockType to use a clock with a different 
number of ticks per second if one exists.

You can also use std.datetime.Clock

-Steve
Dec 22 2015
next sibling parent Tanel =?UTF-8?B?VGFnYXbDpGxp?= <tanel58 hotmail.com> writes:
On Tuesday, 22 December 2015 at 20:07:58 UTC, Steven 
Schveighoffer wrote:

 MonoTime uses whatever precision is given to it by the OS. So 
 if on your OS, ticksPerSecond is 1e9, then your OS clock wraps 
 at 18 hours as well.


Thanks, I didn't know that.

I actually just realized that my use case doesn't need to rely on 
absolute clocks, so I'm safe.
Dec 22 2015
prev sibling parent Jonathan M Davis via Digitalmars-d-learn writes:
On Tuesday, December 22, 2015 15:07:58 Steven Schveighoffer via
Digitalmars-d-learn wrote:

 MonoTime uses whatever precision is given to it by the OS. So if on your
 OS, ticksPerSecond is 1e9, then your OS clock wraps at 18 hours as well.


1e9 ticks per second should still take over 293 years to wrap around.

    writeln(seconds(long.max / cast(long)1e9));

prints out

    15250 weeks, 1 day, 23 hours, 47 minutes, and 16 secs

Even if the clock ticks were in picoseconds (1e12 ticks per second), the
clock would still take over 15 weeks to wrap around from 0.

The OP's

    writeln(mt.ticks / mt.ticksPerSecond / 60 / 60); // prints 18 (hours)

simply indicates that the system clock thinks that 18 hours have passed
since the start of the system clock. And there's no guarantee that the
system clock starts at 0, so while it's a bit weird for it to be in the
range of 18 hours shortly after boot, it's perfectly legal. The only risk
would be if the clock started close enough to long.max to cause the clock to
wrap around even though it would have had plenty of room at 0.

So, unless I'm missing something here, there is no problem, and MonoTime
will work fine for what the OP is looking to do. As I recall, in the initial
PR for Monotime, we discussed its range based on various clock frequencies
and concluded that long was plenty large for any clock frequency we were
ever going to see; otherwise, we probably would have gone with something
similar to what POSIX uses (timespec) and split out the seconds and ticks
per second rather than simply use ticks per second.

- Jonathan M Davis
Dec 22 2015