Grand Central Dispatch

【Grand Central Dispatch】

　　GCD is one of the technologies for starting tasks asynchronously. This technology takes the thread management code you would normally write in your own applications and moves that code down to the system level. All you have to do is define the tasks you want to execute and add them to an appropriate dispatch queue. GCD takes care of creating the needed threads and of scheduling your tasks to run on those threads. Because the thread management is now part of the system, GCD provides a holistic approach to task management and execution, providing better efficiency than traditional threads.

【Dispatch Sources】

　　Dispatch Source 按作用来说，称为Monitor更合适。

　　Whenever you interact with the underlying system, you must be prepared for that task to take a nontrivial amount of time. Calling down to the kernel or other system layers involves a change in context that is reasonably expensive compared to calls that occur within your own process. As a result, many system libraries provide asynchronous interfaces to allow your code to submit a request to the system and continue to do other work while that request is processed. Grand Central Dispatch builds on this general behavior by allowing you to submit your request and have the results reported back to your code using blocks and dispatch queues.

　　从用户态切换到内核态会有不容忽视的时间开销，因此，很多系统库提供提供request的异步接口，使得当你的请求被处理时，你可以做其它工作。Grand Central Dispatch基于此行为构建，允许你提交request，并把results通过block和dispatch queue机制来返回给你。

　　Dispatch sources replace the asynchronous callback functions that are typically used to process system-related events. When you configure a dispatch source, you specify the events you want to monitor and the dispatch queue and code to use to process those events. You can specify your code using block objects or functions. When an event of interest arrives, the dispatch source submits your block or function to the specified dispatch queue for execution.

　　Dispatch Source 替代了用于处理系统相关事件的古老的Callback机制。当你配置一个dispatch source，你指定想到监听的事件、dispatch queue以及代码。代码可以使用block对象或function。当监听的事情到达，dispatch source提供你的代码到关联的dispatch queue。

　　Dispatch sources retain their associated dispatch queue to prevent it from being released prematurely while events may still be pending.

　　To prevent events from becoming backlogged in a dispatch queue, dispatch sources implement an event coalescing scheme. If a new event arrives before the event handler for a previous event has been dequeued and executed, the dispatch source coalesces the data from the new event data with data from the old event. Depending on the type of event, coalescing may replace the old event or update the information it holds. For example, a signal-based dispatch source provides information about only the most recent signal but also reports how many total signals have been delivered since the last invocation of the event handler.

　　为了防止消息积压，dispatch source 会把新老消息的数据合并。根据dispatch source类型，会决定是replace或是update。

【Creating Dispatch Sources】

　　If your event handler is already queued and waiting to process an event when a new event arrives, the dispatch source coalesces the two events. An event handler generally sees information only for the most recent event, but depending on the type of the dispatch source it may also be able to get information about other events that occurred and were coalesced. If one or more new events arrive after the event handler has begun executing, the dispatch source holds onto those events until the current event handler has finished executing. At that point, it submits the event handler to the queue again with the new events.

　　当handler已经入队列，但还未执行时，dispatch source会合并消息。当handler开始执行后，dispatch source会预留住消息，等当前handler处理完毕后，再提供一个新的handler到队列。

【Changing the Target Queue】

　　Although you specify the queue on which to run your event and cancellation handlers when you create a dispatch source, you can change that queue at any time using the dispatch_set_target_queue function. You might do this to change the priority at which the dispatch source’s events are processed.

　　Changing a dispatch source’s queue is an asynchronous operation and the dispatch source does its best to make the change as quickly as possible. If an event handler is already queued and waiting to be processed, it executes on the previous queue. However, other events arriving around the time you make the change could be processed on either queue.

【Memory Management for Dispatch Sources】

　　Like other dispatch objects, dispatch sources are reference counted data types. A dispatch source has an initial reference count of 1 and can be retained and released using the dispatch_retain and dispatch_release functions. When the reference count of a queue reaches zero, the system automatically deallocates the dispatch source data structures.

　　Because of the way they are used, the ownership of dispatch sources can be managed either internally or externally to the dispatch source itself. With external ownership, another object or piece of code takes ownership of the dispatch source and is responsible for releasing it when it is no longer needed. With internal ownership, the dispatch source owns itself and is responsible for releasing itself at the appropriate time. Although external ownership is very common, you might use internal ownership in cases where you want to create an autonomous dispatch source and let it manage some behavior of your code without any further interactions. For example, if a dispatch source is designed to respond to a single global event, you might have it handle that event and then exit immediately.