Waht do you think about my repeated_timer class

[Cecil Westerhof]

Barry <barry at barrys-emacs.org> writes:

>> On 3 Feb 2022, at 04:45, Cecil Westerhof via Python-list <python-list at python.org> wrote:
>> 
>> Have to be careful that timing keeps correct when target takes a 'lot'
>> of time.
>> Something to ponder about, but can wait.
>
> You have noticed that your class does call the function at the repeat interval but
> rather at the repeat interval plus processing time.

Nope:
        def _next(self):
            self._timer = Timer(self._interval, self._run)
            self._timer.start()

        def _run(self):
            self._next()
            self._fn()

In _run I first set the new timer and then I execute the function. So
that will go mostly OK.


> The way to fix this is to subtract the last processing elapsed time for the next interval.
> Sort of a software phase locked loop.
>
> Just before you call the run function record the time.time() as start_time.
> Then you can calculate next_interval = max( .001, interval - time.time() - start_time)
> I use 1ms as the min interval.

But I am working on a complete rewrite to create a more efficient
class. (This means I have to change also the code that uses it.) There
I have to do something like you suggest. (I am already working on it.)


Personally I am also of the opinion that the function should finish in
less as 10% from the interval. (That was one of my rewrites.)

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof