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?
I believe Rocco is speaking of clock drifts between the system timer or kernel clock and real time. Take a look at <http://www.tldp.org/HOWTO/Clock-2.html> for an explanation.
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).
If you take a look at the postings dated back in April, you will find that such API already exists, it's POSIX::times. There is no need to reinvent the wheel.
Pete
