On Viernes 10 Julio 2009, Leslie P. Polzer wrote:
> Gábor Melis wrote:
> > Are there jobs scheduled to run at that time (maybe some BDB
> > maintanance)?
> Okay, got it. This occurs because of a system time shift
> initiated by an 'rdate' run.
> Now the only remaining question if what we should do about
> things of that sort. They obviously break the timer signal
> chain but must not do so.
Haha, try this:
diff --git a/src/code/timer.lisp b/src/code/timer.lisp
index b84168a..065b4c2 100644
@@ -363,6 +363,11 @@ triggers."
(when (or (null timer)
+ ;; Seemingly this is a spurious SIGALRM, but play it safe and
+ ;; reset the system timer because if the system clock was set
+ ;; back after the SIGALRM had been delivered then we won't get
+ ;; another chance.
(return-from run-expired-timers nil))
(assert (eq timer (priority-queue-extract-maximum *schedule*)))
Also, I've verified that setitimer itself is resistant to tinker with
the system clock, at least on my desktop. The attached program imitates
the call pattern of a Lisp interval timer. Setting the clock backward
and forward does not pose any difficulty to it.