swift-corelibs-libdispatch: the C concurrency runtime behind Swift on Linux
The libdispatch Project, (a.k.a. Grand Central Dispatch), for concurrency on multicore hardware
At a glance
- What is it?
- This repository is the open source implementation of Grand Central Dispatch for non-Darwin platforms, shipped inside every Swift release since Swift 3. The README describes a completed port and lists what contributors can still pick up.
- Who is it for?
- You will not choose this library the way you choose a package, because it arrives inside your Swift toolchain and your Linux build depends on it being there. The interesting question is what it does not do: the README is explicit that the Linux version is built on pthread primitives rather than the xnu kernel's scheduler, so thread placement is not informed by global system load.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 10, 2026, and from our analysis. They are not legal advice.
Editorial analysis
One runtime, two very different implementations underneath
The README opens by describing what libdispatch provides, comprehensive support for concurrent code execution on multicore hardware, and then immediately draws the distinction that matters to anyone benchmarking on Linux. On Darwin, libdispatch is a combination of logic in the xnu kernel alongside the userspace library, and the kernel has the most information available to balance workload across the entire system.
On Linux the same API is served from userspace. The README says the project's approach was to bring up the basic functionality of the library using userspace pthread primitives first, and it mentions that eventually a Linux kernel module could be developed to support more informed thread scheduling.
So two things follow. First, the API surface is portable, which is the point of the project. Second, the scheduler underneath is not the same implementation, and a task that lands on a thread pool thread rather than a kernel-placed workqueue thread can behave differently under load. That is not a bug, it is a documented design boundary, and it is the first thing to know before drawing conclusions from performance numbers taken on one platform and expecting them to transfer.
That future kernel module is described as something that could be developed, not something in progress. Nothing in the project status section claims work on it.
The port is done; the test suite is not
The project status section is short and worth quoting closely in substance rather than wording. It says a port of libdispatch to Linux has been completed, and that since Swift 3, swift-corelibs-libdispatch has been included in all Swift releases and is used by other swift-corelibs projects.
That single fact reframes the repository. This is not a library you evaluate and pin in your dependency manifest. It is part of the toolchain, which means your Linux and Windows builds get whatever version your Swift release carries, and your upgrade cadence for this code is your Swift upgrade cadence.
The two listed opportunities for contribution are a test suite for the Swift APIs of libdispatch, and enhancing libdispatch as needed to support Swift language evolution and the needs of the other Core Libraries projects. That is an unusually candid pairing. The C library is considered ported; the Swift-facing wrapper around it is where the work is.
For a reader trying to size the project, the repository tree is consistent with a mature C library: `dispatch/` for the core, `src/` for the platform-specific sources, `os/` for the operating system abstraction, `resolver/` for the portable subset, `private/` for internal headers, `tests/`, `tools/`, plus `CMakeLists.txt`, `cmake/`, `config/` and `man/`. The `libdispatch.xcodeproj/` directory explains how the same sources still build on the Apple side.
Build and test instructions live in two other files
The README does not contain a single command. It points to `INSTALL.md` for building and installing the library and to `TESTING.md` for testing it. Both files exist in the repository root alongside `README.md`, `LICENSE`, `PATCHES`, `TESTING.md`, `INSTALL.md` and `CMakeLists.txt`.
This is the honest shape of the project. Building libdispatch is a CMake job with platform detection, not a two line install, and the instructions that matter are in `INSTALL.md`. Since the library ships inside the Swift toolchain, the far more common acquisition path is installing Swift rather than building this yourself.
`PATCHES` in the root is a detail that tells you how the project relates to its upstream. libdispatch originally came from Apple, and a PATCHES file at the root of a port implies the delta from that origin is tracked explicitly rather than accumulated invisibly in commits. That is useful when you want to know how much of the code is portable subset and how much is Linux adaptation.
The `man/` directory also tells you the library takes its user documentation seriously enough to ship manual pages alongside the code, which is rare for a Swift-adjacent C project.
Version tags that track Swift, not the library
GitHub reports the repository as C, Apache-2.0 licensed, not archived, last pushed 2026-09-24, on the `main` branch. The release list is where the tag scheme becomes obvious: swift-6.4.0-RELEASE published 2026-09-15, then swift-6.1.1-RELEASE on 2025-05-24 and swift-6.1-RELEASE on 2025-04-01.
These are Swift release tags, not libdispatch version numbers. There is no v3 or v4 of this library because the library does not version independently; it versions with the language toolchain that ships it. Anyone looking for a semver to pin in a build file will not find one here, and anyone expecting a libdispatch changelog will find the language's cadence instead.
The homepage field is set to swift.org, which is the right place to look for release notes that mention this component. The README itself defers everything operational to the two markdown files in the root and to the wider Swift documentation.
What the Apache-2.0 licence means practically is that you can vendor this code into a product, including a closed-source one, with attribution, which is a materially easier position than a copyleft licence would give you. For code you get by installing a Swift toolchain rather than by cloning, the question is academic, but it matters if you ever vendor the runtime.
Where a cooperative pool sits against other Linux options
The repository's related search terms point at a phrase worth taking seriously: Swift cooperative thread pool. On Linux, Swift's concurrency runtime, which includes structured concurrency and actors, is built on top of this library, and the scheduling model is cooperative rather than preemptive for the task layer. A task does not get time-sliced out mid-flight the way an OS thread does; it runs until it suspends.
That has a real consequence for code you write. A CPU-bound loop inside an async task with no suspension point can occupy its executor without yielding, which is the classic way cooperative pools disappoint people arriving from preemptive thread scheduling. The fix is to break the work up or move it off the pool, and knowing that the runtime is cooperative from the start saves the debugging session.
The alternatives on Linux are not really alternatives. Rewriting the concurrency layer would mean abandoning Swift's structured concurrency model, and swapping in a native thread pool means giving up the structured guarantees that come from the standard library's design. For cross-platform Swift code, libdispatch on Linux is the reason async and await behave similarly on both operating systems, which is a quiet but real service the project performs.
Where it is genuinely not the answer is platform-specific C work with tight scheduling requirements, where the pthread-based implementation has no kernel assistance in placing threads.
Reading the source tree as a map of the abstraction
The directory names give you the layering without opening a header. `os/` is where the platform-specific pieces live, which is the concrete form of the pthread-versus-kernel distinction the README describes. `resolver/` handles selecting implementations at build time, which is how a single library can offer a portable subset on Linux while Darwin keeps its own. `private/` holds internal interfaces that are not part of the API contract, and `dispatch/` holds the public surface.
`xcodescripts/` and `xcodeconfig/` alongside `libdispatch.xcodeproj/` are a reminder that this is not a Linux-only project. The same tree builds on Apple, with Xcode as a first class path, and the Linux build is the port rather than the original.
The `.gitmodules` entry in the root indicates at least one dependency arrives as a submodule, which is common for this kind of C project and relevant if you mirror the repository, since a shallow clone without submodule initialisation will not build.
Taken with the push date of 2026-09-24 and the swift-6.4.0-RELEASE tag eleven days earlier, the picture is a library in maintenance mode that still moves with every language release, with the open work sitting in Swift API coverage and in following language evolution rather than in new C functionality.
Editorial conclusion
You will not choose this library the way you choose a package, because it arrives inside your Swift toolchain and your Linux build depends on it being there. The interesting question is what it does not do: the README is explicit that the Linux version is built on pthread primitives rather than the xnu kernel's scheduler, so thread placement is not informed by global system load. GitHub reports the last push on 2026-09-24, and the swift-6.4.0-RELEASE tag of 2026-09-15 shows it tracking the language release cycle rather than versioning independently.
Frequently asked questions
How do I build libdispatch on Linux?
The README does not carry the commands and defers to `INSTALL.md` in the repository root for detailed build and install instructions, and to `TESTING.md` for testing. The build is driven by `CMakeLists.txt` with platform detection under `cmake/` and `config/`, and it is worth noting that in practice most users get this code by installing a Swift toolchain rather than building it themselves.
Do I need to install swift-corelibs-libdispatch separately for my Swift project?
No. GitHub reports that since Swift 3, swift-corelibs-libdispatch has been included in all Swift releases and is used by other swift-corelibs projects, and the README calls the Linux port complete. It arrives with the toolchain, so there is no separate dependency to add or version to pin.
Is libdispatch on Linux the same implementation as on macOS?
The API is the same, the implementation underneath is not. The README says the Darwin version combines xnu kernel logic with the userspace library, while the Linux port is built on userspace pthread primitives as a first step, with a possible Linux kernel module mentioned as a later possibility rather than current work.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/swiftlang-swift-corelibs-libdispatch)