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
the list and notifies any caller whose time has expired (stopping at the 
first time
which is still in the future, if the list is ordered).

There would be no dependency on wall clock time - and one could probably
even expect a finer grained control than 1 msec - non-GUI apps, of course - on
my (somewhat dated PC) this timer runs at 1.8 GHz.

Ok, I apologise if I am off topic - but it sounded strangely familiar with 
something
I just did with an embedded controller.
Best regards
Helmut Giese

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08