[markpapadakis]

I ported GCD to Linux when it was made available/open-sourced some many months ago. Effectively, GCD uses a bunch of (named) FIFO queues, protected by semaphores, and manages some OS threads, which dequeue tasks(or blocks) from the queues and execute them. It provides some nice higher level abstractions and functionality (e.g groups ) on top of that. It also supports both synchronous and asynchronous execution semantics. The OS threads are of course managed by the OS scheduler. (unfortunately, pthread workqueues are not supported on Linux yet -- the original implemntation creates workqueues for each defined priority and that's how priorities are supported in GCD. On Linux you can use setpriority(), ioprio_set() and other such APIs that don't really offer much in practice. But I digress).

Contrast that to coroutines/fibers where tasks(i.e functions), which run in the same I/O thread(though not an absolute requirement). Cooperative multitasking is used, where a running function can yield control to other runnable functions by explicitly calling a yield like function -- that is, there is no scheduler that preemptively stops a function and runs another. You need to do that yourself.

There is some overlap between the benefits and properties of tasks that run on OS threads and fibers, but for the most part, they have different pros and cons. You can't really use in practice fibers to get the benefits you get from a GCD like framework (which utilizes multiple H/W cores to run functions/tasks concurrently), but also, you can't use GCD to improve throughput on a per-thread basis and deal with long-running and/or blocking lightweight tasks, or implement a fair-scheduling execution scheme).