Comment by JoeAltmaier | Hacker News Reader

Comment by JoeAltmaier | Hacker News Reader

OS time handling is feeble across the industry. Its inherited from 20-year-old ideas about APIs. Not just the antique time structures that are useful for rendering but not much else. Also the abominable Sleep() and such.

Imagine you want to do something every second. You Sleep(1000) or some such. But it takes time to do the thing, so its actually a bit longer between loops. Maybe it doesn't matter; maybe it does. But you're stuck doing stuff like that.

Why not Wait(timetowaitfor). Not a duration; the actual time you want to be woken up. Now it still takes time to wake up and run. And it takes time to make the call. But now, your stuff actually runs say 60 times per minute (e.g. if you wait for successive seconds), hour after hour and day after day.

Also, what's with limited resolution on the time? Its due to the common implementation of timers as a counter of ticks, where a tick is whatever regular interval some hardware timer is set to interrupt. Why not instead interrogate a free-running counter? And if I want to wait 1 second plus 150 nanoseconds, then I Wait for that time to arrive, and the library (or OS) set a real timer interrupt to go off when that time has arrived? Sure there's latency in calling me back; that's inevitable. What's not inevitable is some limited multi-millisecond tick resolution.

Anyway, whenever I'm in charge of designing an OS or application environment, I provide real timers like this. It's about time the big OS providers catch up to the 21st century.

> Why not Wait(timetowaitfor). Not a duration; the actual time you want to be woken up. Now it still takes time to wake up and run. And it takes time to make the call. But now, your stuff actually runs say 60 times per minute (e.g. if you wait for successive seconds), hour after hour and day after day.

There's a lot of "what ifs" that need to be answered for something that seems so simple:

* What clock are you using? Machine ticks? Wall clock? Is it correct? Is it stable enough?

* What if the clock misses the time that I asked for? Do you run it anyway? Do you skip that invocation?

* What if the clock moves backwards? Will you trigger twice? Will you even notice?

* What if I have a leap second so there are 61 seconds in the hour? What if a second is removed so there are 59 seconds in the hour?

The reason why people don't touch this stuff or get it wrong is because it's really hard. There's a lot of corner cases when it comes to time handling.

Really hard things are what OS code is FOR. Get it right once; then apps call it and it works.

You can already do this in POSIX.1-2001-conforming systems like Linux using `clock_nanosleep` (http://man7.org/linux/man-pages/man2/clock_nanosleep.2.html).

Still just a Sleep(), right? So the latency in the callback can be added to the next time, with resulting drift. The idea is, I know when I want to be called back, as an actual number. I want a sleepuntil() that I pass the actual time.

Unless I misunderstood, that's what the TIMER_ABSTIME option is for. This is actually what I use for soft real-time loops, when I'm concerned about both drift and jitter.

Ok thanks, I reread it, that seems to be the case! I hope the seconds field is honored along with ns. WinCE had a bug where they used a long. If latency made your call for a small interval occur after the interval had elapsed, you slept for 19.5 minutes instead (nearly a full count). Combining the ns with a second counter should be enough bits to avoid that.

You probably want to look at setitimer.

Why? That still uses intervals instead of real time indexes.

Reply on news.ycombinator.com