Barry <ba...@barrys-emacs.org> writes:
>> On 3 Feb 2022, at 04:45, Cecil Westerhof via Python-list
>> <python-list@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
--
https://mail.python.org/mailman/listinfo/python-list
