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.
> 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.
> 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.
> P.S. What is an 'egg timer'?
It is a short-duration cooking timer. Sometimes they are small
hourglasses. Sometimes they are timers that you twist to start. I use
them as the real-world analog of delay() timers.
--
Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
