我正在研究multithreading，GCD似乎比使用pthread.h和pthreads-win32手动编写解决scheme更好。 不过，尽pipe看起来libdispatch正在开发或即将开始工作，但是大多数新的POSIX兼容系统…我必须问，Windows怎么样？ libdispatch移植到Windows有什么机会？ 防止这种情况发生的障碍是什么？
如果说到这一点， 我需要做些什么来预制这个portage？
编辑：我已经知道的一些事情，开始讨论：
libdispatch用APR调用replace用户空间libdispatch所有pthread.h依赖项，以实现可移植性吗？ 或者，或者，使用pthreads-win32我想… 编辑1：我听说，这是完全不可能的，永远不会，因为libdispatch （不知何故）取决于kqueue ，它不能在Windows上提供…有没有人知道这是真的吗？
看看： http ://opensource.mlba-team.de/xdispatch/这个项目（和其他第三方库）将libdispatch带入除macosx以外的平台（Windows，Linux）
从我对它的基本理解来看，libdispatch的Windows相当于非托管代码的并发运行时 ，以及统称为托管代码的并行扩展 的技术集合。 在我看来，GCD很好地映射到这两者，因为它们都以相似的方式抽象工作单元（或“任务”）。
从一些研究来看，似乎港口已经有一些公平的利益，但是这个港口将是一个非常艰巨的任务，可能最终基本上只是API的另一个实现，而不是实际上与原始码共享重要的代码libdispatch。 我看到了一些建议，将libdispatch移植到基于Apache Portable Runtime而不是POSIX上，这使得它更容易跨平台到Windows，但即使这样也不是一个容易的改变。
可能，这绝不是一件小事。
我认为，而不是libdispatch-on-pthreads和pthreads-on-Win32，或libdispatch-on-APR和APR-on-Win32，可能会更好直接在Win32 线程池API上实现libdispatch。 好消息是，这两个API是相似的，你可以自己做端口。 坏消息是可能会有很多的角落案例，这些案例中存在小的语义错配，难以实现准确的行为。