> Consider, that my implementation was based on observations of what
> windows VM doing. And its already used a multimedia timer, which was
> set to trigger checking for interrupts each 1 msec (or at minimum time
> periods which OS can provide, but not less than 1mses). And these
> routines created own timer thread, hidden from the eyes of developer.
> So, what i did, i just replaced this thread by own implementation.
> Also, because of using multimedia timer, i seen an ovelap: an
> optimistic ( interruptCheckCounter handling) was doing the same as
> multimedia timer does, which, IMHO, can't be considered as a good
> algorithm.
>
> After refactoring, i got a code which can handle timer with better
> accuracy comparing to old VM. (Read a topic some time back about
> Delays accuracy).
> In fact, i was surprised, when seen, that my implementation provides
> more accurate timers, i expected it to be worser :)

Ok, I'll have to run some benchmarks, when I changed the macintosh VM  
to pound the interrupt delay
logic 1000 a second back in the era of 500 Mhz machines the impact on  
performance was noticeable.
Maybe today no one cares, maybe the folks chasing the why does opening  
windows take 2x as long
can fix that, then mmm we'll consume part of the gain back in overhead  
to improve Delay accuracy.

Maybe I can clock watch before handleEvents() to avoid the overhead of  
a timer routine.

I note we use to have clock watching on each primitive call in ages  
past, but removed it since we
found that under certain conditions one could spend % of time just  
getting the clock, some vestiges
of that lurk via the non-existant lowres millisecond clock function.  
Maybe it's not noticeable now.

Ya, benchmarking first...

--
= 
= 
= 
========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
= 
= 
= 
========================================================================