On Fri, Aug 29, 2003 at 02:29:48PM -0400, Dmitri Tikhonov wrote:
> 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:
> > > 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?
There is a small yet finite amount of time spent in handling the event
and setting the alarm.
http://poe.perl.org/?POE_Cookbook/Recurring_Alarms discusses the issue
and includes two short programs to illustrate it.
> > > 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).
I would be happy to use an externally maintained monotonic time source.
Like Time::HiRes, though, it should support 1/100 to 1/1000 second time
resolution.
--
Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
