Re: Repeating timer firing way to fast

Quincey Morris

On May 22, 2018, at 04:15 , Jonathan Taylor <jonathan.taylor@...> wrote:

and therefore the timer callback blocks

It seems to me that this could be regarded as a bug in your design. The consequence of blocking, at a higher conceptual level, is that it destroys the concept of timing which is essential to your task.

One alternative is to use the timer callback *only* to decide whether it has been 4 or more seconds since the last time the secondary process action finished (or, more than 4 seconds since it last started, *and* that it has finished), and, if so, to trigger the action asynchronously. The precise details will depend on how you want the system to behave in the face of delays.

Or, you could switch to a recurring NSTimer. That has an API contract about what happens when scheduled firings are missed:

"After a repeating timer fires, it schedules the next firing for the nearest future date that is an integer multiple of the timer interval after the last scheduled fire date, within the specified tolerance. If the time taken to call out to perform a selector or invocation is longer than the specified interval, the timer schedules only the next firing; that is, the timer doesn't attempt to compensate for any missed firings that would have occurred while calling the specified selector or invocation.”

Join to automatically receive all group messages.