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.
Maybe the better thing to do is to use a standard API such as POSIX::times as a default. This solves the problem uniformly for platforms that have *proper* implementations of POSIX. This is probably preferable to using a non-portable Linux specific interface such as /proc/uptime. In cases where a monatomic increasing POSIX::times does not exist, support can be added for a platform specific monatomic timer.
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?
Is there any particular advantage of replacing ST_TIME w/ ST_ALARM? ST_TIME uses the old system time based semantic. Isn't what we are trying to do here simply to add a "delay" based semantic? How about keeping ST_TIME and adding ST_DELAY?
Pete
