What does it mean that input sources such as port deliver events to a run loop async while timers deliver events synchronously.
Does the timer block the thread?
2
votes
1 Answers
0
votes
The Threading Programming Guide: Run Loops says:
A run loop receives events from two different types of sources. Input sources deliver asynchronous events, usually messages from another thread or from a different application. Timer sources deliver synchronous events, occurring at a scheduled time or repeating interval. Both types of source use an application-specific handler routine to process the event when it arrives.
But a timer only blocks the thread while the timer’s closure or selector method is running. But as soon as you return from that, the thread is no longer blocked. So make sure to get in and out as quickly as possible.
For example, if you have scheduled a timer to fire in 10 seconds, and the code in the timer’s handling closure/selector takes 100 msec to run, then the thread is not blocked until the timer fires, and then only for 100 msec. Same with repeating timers.
Bottom line, as long as you’re not doing anything too computationally expensive in your timer handler, there’s nothing to worry about. And if you do need to do anything that might block for any material amount of time, then either have your timer handler asynchronously dispatch that relevant code to some background queue, or just schedule a GCD timer to run on a background queue directly, bypassing Timer altogether.
But for most Timer use-cases, this just isn’t an issue.
