Re: after ids (Helmut Giese)

>Donal K. Fellows wrote
>While I could always see how to do it with single sets of timers, I
>could never work out how to do it reliably with multiple event
>sequences on different scales (e.g. a 13ms interval and a 1s interval)
>where the event processing takes an appreciable time w.r.t. the
>shorter intervals. Which happens for sure when using, say, Tk; redraws
>are quite expensive. With each pending timer event assigned an
>absolute time at which it becomes eligible for execution, it's pretty
>simple to handle. But without it...

Could well be, that I am way off of what is discussed here, but what I
understood seems rather easy to realize (at least on PC hardware).
Here's the idea:
Any reasonably recent PC hardware has a free running 64 bit timer
(sometimes called the Multi Media Timer) - since Pentium 1 IIRC.
There are 2 system calls:
- Query this timer's frequency (QueryPerformanceFrequency) and
- get its current count (QueryPerformanceCounter).

On startup Tcl would ask for the frequency and would once calculate the
number of timer ticks to a millisecond.
Now someone comes along and wants to be notified after 10 msec. Ok,
Tcl gets the current timer value, adds the appropriate value for 10 ms and
puts the timeout value into a list.
1 msec later someone else comes around and asks for a delay of 3 msec.
Tcl does the same and (this would be a micro-optimisation) orders the list, so
that the new event is placed _before_ the one from step 1.

At any moment when Tcl wants to check if any timer event has expired, it walks