Re: after ids (Helmut Giese)

Helmut Giese wrote:
>> 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).

The performance counter and the multimedia timer are different
beasts.  The multimedia timer clicks with at best millisecond
granualiry, and mostly is used by games and video players to get
interrupts at frame rate.

> 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.

This is what we do.

> 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).

This is also what we do.  The issue, though, is that we do more than
*check* for whether a timer has expired.  We also get to the point
where Tcl has nothing to do but wait for the next timer, I/O completion,
mouse click, or whatever.  At that point we need to *wait* until
a given time.  I'm sure that you don't want your Tcl apps all busy
waiting and using 100% CPU when they're idle, so we need to use the
OS facilities to wait.  There is no facility to wait for a particular
value of the performance counter, so we have to us the kernel
facilities, and we're back to at best millisecond granuarity.
We also then need to keep the performance-counter-based notion of
time in sync with the kernel time. That gets tricky - I've seen
perf counters that were 200 ppm off-frequency with respect to
their stated rates, and they vary with temperature, and on laptops
they also vary as the processor clock is slowed down to save
the battery.

> 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.

You have a multicore system then. On single-core machines the
perf counter ticks over at 1.8 or 3.57 MHz, not GHz.

In any case, read tclWinTime.c -- virtually all of what you suggest
is already there.  Much more on how it was built can be gleaned
from http://tip.tcl.tk/7

--

-- 
73 de ke9tv/2, Kevin

-------------------------------------------------------------------------
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