PeriodTicks type is
uint32_t (so its max value is 4294967295) and
1000000 on my system, so the max periodMs is 4.294 seconds.
So we can’t have a
HighResolutionTimer with a longer period than that.
Should we have an assertion in
startTimer() to catch that?
perhaps the value should be clipped to avoid the overflow?
This won’t affect the period of the timer since we rely on a condition variable to do the actual callbacks - the purpose of the
setThisThreadToRealtime() function is to set the thread policy for the high-res timer thread.
As per the POSIX docs, the
period is “the nominal amount of time between separate processing arrivals” and can have a value of 0 to indicate that there is no “inherent periodicity” in the calculation happening on the realtime thread. From testing it seems that we do want to set this to some value since that results in more accurate callbacks, but it doesn’t need to be the period of the timer. Just constraining the value of
periodTicks to prevent the overflow and remove the warning seems to work well and I’ve pushed that to develop here:
oh, sorry for my misunderstanding. thanks for clearing things up and for the commit ed!