When will clock_gettime() return a smaller value, using CLOCK_MONOTONIC, due to reaching it's maximum value? I don't mean the little warps that have been described as bugs, but something like a counter reset.
Is it time measured, or is it related to the absolute number of ticks?
I have to implement a timer (1 or 2 second intervals), and i don't need that much precision. But the aplication may be running several hours without restarting. (i estimate 1 day max).
I wan't to be shure i won't make any mistakes that may lead to it stop comunicating.
Does timerfd already takes care of this issue?
As struct timespec uses a time_t value for seconds, the complete range that can be covered is at least 68 years. Given the definition of CLOCK_MONOTONIC as starting at some arbitrary point, in theory clock_gettime could overrun anytime. In practice, you only need to worry about this if your app runs for some decades. But, if you're paranoid, make a wrapper function that complains loudly and kills the application if a timer wraparound happens.
CLOCK_MONOTONIC, as implied by the "monotonic" name never goes back in time, it is always growing. Will not change if the user or another process (like NTP) changes the "wall" clock on the machine. CLOCK_MONOTONIC is the right timescale to use in timers. It can eventually roll over but even that can be handled cleanly if you do it carefully. Use the same type of variable for the internal timer.
For example the following code will work OK eve if the clock wraps around. Note: kDelayInterval has to be smaller than the wrap around period (this is normally not a problem).
struct timespec current_time; struct timespec last_update = {0,0}; . . clock_gettime(CLOCK_MONOTONIC, ¤t_time); if((current_time.tv_sec - last_update.tv_sec) > kDelayInterval) { . . . clock_gettime(CLOCK_MONOTONIC, &last_update); }
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With