Why observer notifications for timer and input sources are delivered before those events actually occur in run loop sequence of events

Question

I am learning how to use NSRunLoop and reading Apple Doc about Run Loops chapter.

I am confused about some description about how the doc states about the the run loop sequence of events

Because observer notifications for timer and input sources are delivered before those events actually occur, there may be a gap between the time of the notifications and the time of the actual events. If the timing between these events is critical, you can use the sleep and awake-from-sleep notifications to help you correlate the timing between the actual events

Here is doc link

It says observer notifications for timer and input sources are delivered before those events actually occur. Since those events being not happened, how does run loop knows those events are about to happen and sends notifications for thoes events in advance?

Answer 1

After many searches, It may help.

The doc says the followings in Custom Input Sources section.

In addition to defining the behavior of the custom source when an event arrives, you must also define the event delivery mechanism. This part of the source runs on a separate thread and is responsible for providing the input source with its data and for signaling it when that data is ready for processing. The event delivery mechanism is up to you but need not be overly complex.

More details link1 and link2

The event may occur, but that event may not be ready for using, cause the actual data produced by that event, processed on a separate thread, may not be enough to trigger the thread, which is listening that notification. So their is a gap between the notification posted by run loop and the finished happen event.

There are also other processes that leads to that gap, such as timer input source etc.

Anyone has better explanation?