tic() should use monotonic clock

[jayschwa]

tic() and friends use the system time for measuring duration. This can be problematic if the system time is changed between measurements:

tic()
toc()
now = int32(time())
tic()
# move system time backwards
run(`date --set="@$(now-60)"`)
toc()
# restore system time
run(`date --set="@$(now)"`)

yields

elapsed time: 0.01815319061279297 seconds
Mon Mar  4 16:05:30 EST 2013
elapsed time: -60.13567399978638 seconds
Mon Mar  4 16:06:30 EST 2013

It would be better to use a monotonic clock for any place where duration is being measured, independent of datetime. Examples:
http://linux.die.net/man/3/clock_gettime
http://docs.python.org/3/library/time.html#time.monotonic

[jayschwa]

Nice one.

I also noticed clock_now() being used for some measurement purposes in /src/gc.c and tests. It probably wouldn't be a bad idea to eventually switch those to something else as well.

[StefanKarpinski]

Is time_ns really a monotonic interface?

[jayschwa]

The change resolves my little test. The date command changes the OS clock,
but not necessarily the hardware clock. I will see if I can test that as
well.

[jayschwa]

I added a run(hwclock --systohc) after calling the date command. The duration doesn't seem affected. Working well 😄

[JeffBezanson]

Yes, it uses uv_hrtime which is documented to be monotonic.

[StefanKarpinski]

Great.

[timholy]

Last I checked that even agreed with what was in the libuv source code :-).

I guess we shouldn't be worried about time_ns() overflowing its Uint64 container every ~600 years? If we have to fix that bug, we'll be doing well.