Apple has opened the source code of Grand Central Dispatch (GCD), a powerful, system-wide concurrency framework that was introduced in Mac OS X 10.6. The userspace library component of GCD, which is called libdispatch, is now available for download under the terms of the Apache Software License. This will potentially make it possible, though not necessarily easy, for the feature to be adapted for use on other platforms. The source code of Apple's kernel-level GCD optimizations is also available as part of the XNU source tree, but the documentation indicates that kernel changes may not necessarily be required.

Our own John Siracusa's epic Snow Leopard review describes GCD in exhaustive depth so I'll spare you all of the details here. It provides an efficient system-wide threadpool and some high-level programming constructs that vastly simplify parallelization for application developers.

Although GCD is now open for widespread adoption, there are technical and licensing barriers that could prevent it from being used pervasively on alternate platforms. The high-level GCD API makes extensive use of blocks, a C language extension developed by Apple. This feature has not yet been accepted into the upstream GNU Compiler Collection (GCC) mainline, which means that it can't be used on Linux without using Clang and LLVM. There appear to be ways to use GCD without blocks, but wouldn't be pretty or particularly practical. Apple has supplied its source code for several implementations of blocks, including one for the Low-Level Virtual Machine (LLVM) Clang compiler and for the company's own fork of GCC.

Apple's blocks are basically an approximation of closures, anonymous functions that have access to local variables. This concept is adored by Ruby programmers and is also found in a number of functional programming languages. It's an enormously valuable language feature that can be used to simplify code in a wide range of scenarios, not just concurrency.

For example, using blocks for event callbacks would lead to cleaner and more maintainable code in many cases, particularly in user interface programming. Blocks would also allow C programmers to use graceful functional programming patterns for manipulating collections. Making GCD more portable is obviously just one of many advantages that would come if the GCC developers were to embrace blocks and endorse Apple's effort to make the feature an official part of the C language standard.

GCD aside, if you look at the really elegant high-level frameworks for application-level threading that we have today on Linux, it's breathtakingly obvious that they could be made better by adding support for blocks. The QtConcurrent library, for example, is built almost entirely around the map/reduce paradigm, where Apple's syntactically slick closures would be a perfect fit.

Now that I've outed myself as a functional programming enthusiast, I'll get back to the topic of GCD on Linux. The blocks implementation is under the MIT license, which is GPL-compatible. This means that there aren't any licensing impediments preventing it from coming to upstream GCC. The libdispatch code, however, is distributed under the Apache license, which is unfortunately not compatible with GPLv2 for a handful of truly inane and exasperating reasons. This compatibility issue was resolved in version 3 of the GPL.

The implication for GCD adoption is (unless I'm overlooking something) that libdispatch can't be used in GPLv2 applications. Most Linux applications are v2 "or later" which means that they can be used under the terms of either v2 or v3. But some applications are v2-only and cannot be mingled with Apache-licensed code. This is probably going to be problematic and could contribute to skepticism about GCD among Linux developers. Despite the impediments to Linux adoption, Apple's move to open GCD is still an extremely positive and valuable contribution to the open source software community.

Further reading