On Saturday 27 May 2006 15:01, Clemens Fruhwirth wrote:
> At Thu, 25 May 2006 23:18:20 +0200,
> G=E1bor Melis <mega@...> wrote:
> > > Anything I should change before
> > > someone considers merging?
> > It looks fine to me. The only doubts I have are related to
> > sb-sprof. The timer implementation has some overhead plus the
> > repeat support is naive: the current sb-sprof implementation leaves
> > it to setitimer to repeat the signal, while the timer in sbcl
> > reschedules the timer for every repetition and that involves a heap
> > insert and a setitimer call. It's easy to see why this makes it
> > easy to deal with for example two repeating timers with different
> > intervals, but it should be possible to optimize some of that
> > overhead away.
> I think we don't need to take care of 'overhead' as in 'the overhead
> that slows down the whole application when using sb-sprof'. But we
> need to think about 'overhead' as in 'overhead that causes inaccurate
> sb-sprof profiling results because of self-profiling'. The later one
> can be solved quite easily: do the timer rescheduling after sb-sprof
> has run.
> Make :repeat-interval of schedule-timer to take a list with the
> following meaning
> (<repeat-interval>) same as original <repeat-interval>
> (<repeat-interval> :pre-schedule) - current semantic
> (<repeat-interval> :post-schedule) - reschedule after timer function
> has run.
Post schedule is easy enough to maintain on your own by rescheduling the=20
timer from its timer function. What is 'same as original'?
> BUT this actually a very narrow view of the whole situation. At the
> moment it is possible for timers to interrupt themselfs, as run-timer
> is called with-interrupts, and run-timer (before calling the timer
> function) does reschedule-timer which might lead to setitimer under
> sufficient conditions (also the called timer function might decide to
> call schedule-timer/cancel-timer somewhere causing another reason to
> reschedule). Hence, timer functions can interrupt each other.
Yes. And it's by design too.
> further if that takes too long for one timer, so that his
> total-executing-time-including-all-interrupts is longer than
> repeat-time, but is on top of the priority queue, the delta in
> set-system-timer will actually be negativ, because the point in time
> for which the timer should be scheduled has passed already. I have no
> idea what's going on after that. Either it's catched when converted
> to unsigned, or a really large value will be handed to setitimer,
> virtually killing all timer execution.
> Can someone verify my conclusions? The problem starts at
> src/code/timer.lisp:run-timer. And actually, - hmm when I'm thinking
> about a bit more - there also seems to be a problem without other
> timers involved. Simply imagine a repeating timer's function to
> take a long time. set-system-timer is called in the unwind of
> run-expired-timers, but it might be asked to reschedule a timer for a
> point in time that's in the past.
In real-time->sec-and-usec of all places there is a test for negative=20
But it's true that a single long running single-shot timer function can=20
delay the whole queue because set-system-timer is called after the=20
function returns. Repeating timers are rescheduled before their=20
function is called. That's inconsistent.
Maybe (read I'm pretty sure) it would be better to do the=20
rescheduling/sys-system-timer bit in run-timer *always* (before running=20
And SB-SPROF could do the reschedule on exit trick to avoid profiler=20
> Enlighten me please.