On Fri, Aug 29, 2003 at 01:05:55AM -0400, Rocco Caputo wrote:
> On Thu, Aug 28, 2003 at 05:27:22PM -0400, Dmitri Tikhonov wrote:
> > I was looking at POE::Kernel again to try to figure out this problem, and
> > then I re-visited this thread. It hit me that because of semantic
> > differences between alarm() and delay(), POE::Kernel would have to use
> > _two_ time scales instead of one it uses right now (system time). In an
> > event loop, delay() wants correct time increments independent of system
> > time. I wrote a proof-of-concept time() subroutine to be used in
> > POE::Kernel that simply read number of seconds from /proc/uptime. No
> > matter what I did with system time, children were reaped at appropriate
> > moments. Fine.
>
> Sounds good, but also full of problems. It will require a lot of
> maintenance to support different monotonic timer functions for each
> operating system.
It appears that we will have to do it...
> > Now let's consider alarms. Alarms that are called with time = time() + 5 are
> > not truly alarms -- they're delays (of course, because of the way alarm is
> > set, the argument specifies actual time). Alarms that specify a future time
> > point independent of current time must use system time to operate. An alarm
> > is expected to be triggered when the clock strikes, thus it is supposed to
> > wait for system time to catch up to it. I don't see how delays can be
> > implemented using alarms or vice versa (ideas?).
>
> I have none. It's useful to define recurring delays in terms of
> $some_time + $some_seconds, because that avoids time drift.
>
> sub do_timer_thing {
> # do some code here
> $kernel->alarm( do_timer_thing => $heap->{next_time} += 5 );
> }
>
> That does something every 5 seconds, without clock drift.
>
> It also uses alarm semantics rather than delay semantics, which means
> it's susceptible to time shifts. Assuming different ST_ALARM and
> ST_DELAY events, you can't make a delay that doesn't succumb to clock
> drift.
I am not familiar with this issue. Why would there be a clock drift?
Aren't we to measure monotonic time using clock cycles? And if there
is a clock drift, how bad is it? How long would a delay have to be to
experience this drift?
> > Implementation of the two scales, it seems, would require two time fields in
> > event struct: ST_ALARM and ST_DELAY (instead of ST_TIME). Depending on which
> > one is set, the appropriate time scale should be used. I am not sure what
> > other consequences this would bring both inside and outside of POE::Kernel,
> > but this approach might be worth a try?
>
> I believe it is worth a try. My current issue is the lack of a standard
> monotonic clock source, and the lack of time to develop a portable class
> to wrap all the various system-dependent monotonic clocks.
Wouldn't it be nice if such monotonic clock source was in ANSI C? What
would you say if I wrote an experimental module for monotonic clock (only
for Linux for now, based on uptime), and it would be an option to
POE::Kernel to either use Time::HiRes::time() or Monotonic::time()?
This would be very useful for solving my problem, because my daemon only
cares about delays. Dual time scale implementation of POE::Kernel can
wait (or be somewhere on a branch).
- Dmitri.
