The Mac maker has issued a code freeze on Snow Leopard APIs, suggesting that development is coming along

May 12, 2009 07:01 GMT  ·  By

Apple has recently seeded its developer community with a new build of Mac OS X 10.6 Snow Leopard, revealing in the seed notes that Chinese handwriting recognition has been included for multi-touch trackpads. The people at AppleInsider took a closer look at those notes, signaling that Apple had taken a major step towards releasing Snow Leopard to the public.

“More specifically,” the report in question says, “Apple is said to have informed recipients of Mac OS X 10.6 Snow Leopard build 10A354 that it has simplified the application programming interfaces (APIs) for working with Grand Central, a new architecture that makes it easier for developers to take advantage of Macs with multiple processing cores.”

Although World of Apple provided the seed notes for Mac OS X 10.6 Snow Leopard Build 10A354, the publication did not point out to an important line of text included with the documentation, where Apple told developers that, “No further API changes are planned for Snow Leopard.” AppleInsider soon revealed the true meaning of the note in question, saying that Snow Leopard was nearing the “final stretch.”

Citing the same people that were familiar with the latest Snow Leopard build, AppleInsider reported  that it was Grand Central “dispatch” methods that were tweaked, or simplified, and that developers had been told that “API changes are now halted in Snow Leopard.” The developers notes (available below in their entirety, courtesy of World of Apple), confirm the former's findings.

Developer Notes

Grand Central Dispatch

This release contains several significant simplifications to the GCD dispatch API as outlined below. No further API changes are planned for Snow Leopard. Please refer to the dispatch API HeaderDoc and man pages for additional information.

Objects and Finalizers

The attribute structures used when creating dispatch queues and dispatch event sources are now reserved for future expansion. All attributes supported in previous releases may now be set on the queue or source object directly.

Suspension of a dispatch queue or source now applies to all aspects of the object lifecycle including finalization. All calls to dispatch_suspend() and dispatch_resume() must be balanced. It is an error to release the last reference to a dispatch object that is in a suspended state.

The finalizer attribute is now exclusively a function pointer that is passed the current context pointer of the queue or source at the time the last reference is released. The finalizer function will be invoked on the object’s target queue.

Dispatch Queues

A new convenience function dispatch_after() has been added. This function submits a block to a queue at the specified time.

The function dispatch_get_concurrent_queue() has been replaced by dispatch_get_global_queue(). It is now possible to set the target queue of a dispatch queue using dispatch_set_target_queue(). The priority of a dispatch queue is inherited by its target queue. In order to set the priority of a queue created with dispatch_queue_create(), simply set the target queue to the global queue of the desired priority level. By default, queues created with dispatch_queue_create() have the default priority concurrent queue as their target queue.

Dispatch Event Sources

All dispatch event source creation functions have been consolidated into a single dispatch_source_create() function. Constants are provided to specify what base type the event source should monitor. All dispatch sources are now created in a suspended state, and a single call to dispatch_resume() must be performed in order to start delivery of events. The dispatch_event_t data type has been obsoleted, and all event data may be obtained from the dispatch_source_t reference directly using dispatch_source_get_data(). In addition, it is now possible to specify a distinct event handler block and optional cancellation block for dispatch event sources. The optional cancellation block will only be invoked as the direct result of a call to dispatch_source_cancel(). The event handler block for a source will not be invoked after a call to dispatch_source_cancel() regardless of whether the optional cancellation block is provided.

The event handler block and cancellation handler block have been simplified to take no arguments. The function pointer variants of these blocks will be passed the current context of the dispatch source at the time the function is invoked.

All timer sources are now interval timers (all other types have been obsoleted). The initial fire time, and subsequent repeat interval of a dispatch timer may be set with dispatch_source_set_timer(). In order to get “one-shot” timer semantics, either use the new dispatch_after() convenience routine, or call dispatch_source_cancel() within the event handler block of a dispatch source timer.

Dispatch Apply

The dispatch_apply() function is intended to operate on logically independent compute-bound blocks. The dispatch runtime may limit the number of blocks that execute concurrently as part of a call to dispatch_apply() to the logical number of cores available on the current machine. As a result, creating dependencies between blocks executing as part of the same dispatch_apply() is not advised. More generally, it is not advised to submit blocks to a dispatch queue, which depend on the result of blocks not yet submitted. Please submit work to dispatch queues in dependency order.

Dispatch Group

It is now supported to wait for the completion of the same dispatch group from multiple threads simultaneously using dispatch_group_wait(). Also, multiple notifications may be installed on the same dispatch group using dispatch_group_notify(), and all notifications will be delivered when the group has completed. However, because the notification is delivered asynchronously, it only indicates that the group was empty at the time it was submitted and does not guarantee that the group is still empty at the time the notification is received.

In addition to adding blocks to a dispatch group with dispatch_group_async(), it is now possible to manually manage group membership using dispatch_group_enter() and dispatch_group_leave(). All calls to dispatch_group_enter() and dispatch_group_leave() must be balanced. It is an error to release the last reference to a dispatch group that is not empty.

Dispatch Time

All time-based dispatch functions have been unified to accept dispatch_time_t parameters. The dispatch_time_t data type may be either an absolute time given by dispatch_walltime() or a machine-dependent relative time given by dispatch_time(). The values of this type are opaque and will not work with integer arithmetic, however the aforementioned functions accept a signed delta in nanoseconds that is applied to the specified base time allowing simple arithmetic to be performed.

Kernel Debug Kit

A Kernel Debug Kit is also seeded alongside this Snow Leopard seed. This package contains debug versions of the Mac OS X kernel and many I/O Kit families for use with GDB remote (two-machine) kernel debugging. These files contain full symbolic information, unlike the equivalent files in a normal Mac OS X installation. Also included are GDB macros useful for kernel debugging, a DEBUG kernel built without compiler optimizations, and a script for simplifying the creation of symbol files.

HE-AAC codec

MPEG-4 High Efficiency AAC (HE-AAC) codec is debuted in SnowLeopard. It is an extension of Low Complexity AAC (AAC-LC) optimized for low-bitrate applications such as streaming audio and podcasts. The sound quality for HE-AAC at 64 kb/s is comparable to AAC-LC at 96 kb/s. For 44.1 kHz stereo audio, the recommended operation range for HE-AAC is 32 - 80 kb/s.