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.
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?). 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? - Dmitri. P.S. What is an 'egg timer'?
