Tony Finch wrote:
>Are there any APIs which have an explicit variable epoch, and which reset
>the clock by adjusting its epoch instead of its counter? This would
>eliminate the need for seperate interval and real-time clocks.

Interval clock and real-time clock remain conceptually distinct.  If you
have a single clock counter alongside a variable epoch, the sum of the
two is the effective real-time clock.  I don't think you're gaining
anything by not reifying it.

Where this concept wins is as an implementation strategy.

When adjusting the counter of a PC RTC, for example, there is a problem
of knowing whether you've done the adjustment when you reboot.  There are
well-known problems with DST adjustments being performed twice, by the
same or another OS, but the same kinds of problems arise even without
attempting to reflect DST in the clock.  If you're collecting data
on how far out the clock is and adjusting the clock accordingly, upon
a reboot you can't tell whether you have made the latest adjustment.
Two OSes sharing the machine don't know about each other's adjustments.

The solution is to just let the clock run, never adjust it, and treat
it as an independent seconds count.  You don't care about it showing
the wrong time, because you don't treat its output as an absolute time.
Instead, collect your data on how far out it is (or rather, what absolute
time -> output function it is computing) and add the epoch in software.
Any number of users of the same clock can do this without treading on
each other's toes.

I don't know of any implementation of this strategy for the PC RTC.
I'll be doing one myself sometime soon, as I'm developing an OS in my
spare time.


Reply via email to