use clock_monotonic_raw if available

[jtolio]

clock_monotonic (at least on linux) is susceptible to changing with ntp. clock_monotonic_raw is preferred.

from the man page:

   CLOCK_MONOTONIC
          Clock that cannot be set and represents monotonic time since some unspecified starting point.

   CLOCK_MONOTONIC_RAW (since Linux 2.6.28; Linux-specific)
          Similar to CLOCK_MONOTONIC, but provides access to a raw hardware-based time that is not subject to NTP adjustments.

[ivan]

Thanks. I think I would prefer to expose both to the user, rather than pick one at compile time. The comments on https://stackoverflow.com/questions/3523442/difference-between-clock-realtime-and-clock-monotonic and https://twistedmatrix.com/trac/ticket/2424#comment:23 suggest that both might be useful. But I don't know how I'd want to expose both before studying exactly how the monotonic clock works on Linux, Windows, OS X, and BSD. (Are theirs sped up and down by NTP?). I don't want to ship a half-baked API that requires users to code OS-specific behavior.

This might be beside the point, though. I don't think Monoclock is any good compared to the ctypes-based alternatives out there. I think I want to get out of the monotonic clock business and point people to some other library. Something like this may work on OS X, Linux, and Windows, on both Python 2 and 3: https://github.com/Lokaltog/powerline/blob/c1ae7f35987d6016c4053eee862cac8620dedfe5/powerline/lib/monotonic.py, though I haven't tried it. If you switch to something else, please let me know what it is.

[ivan]

Another ctypes implementations I found: https://bitbucket.org/enovance/trollius/src/2c802d460ce057d7b425008f8bbff42f591fd7c8/asyncio/time_monotonic.py

[jtolio]

We actually had our own cffi implementation, but we started using yours due to performance. ctypes and cffi can be pretty slow with CPython.

[ivan]

Huh, interesting. I guess there's one reason to keep it around, then.