Grand Central Dispatch (`libdispatch`) 可以在 Windows 上使用吗？
我正在研究多线程，GCD 似乎是一个比使用 pthread.h 和 pthreads-win32 手动编写解决方案更好的选择。然而，尽管看起来 libdispatch 正在或即将在大多数较新的 POSIX 兼容系统上工作……我不得不问，Windows 呢？ libdispatch 移植到 Windows 的机会有多大？阻止这种情况发生的障碍是什么？
如果归根结底，我需要做什么来执行该移植？
编辑：为了开始讨论，我已经知道一些事情：
- 我们需要一个可以在 Windows 上编译的块兼容编译器，不是吗？ PLBlocks 会处理这个问题吗？
- 我们可以使用 LLVM 块运行时吗？
- 为了可移植性，我们不能用 APR 调用替换用户空间 libdispatch 中的所有
pthread.h依赖项吗？或者，或者，使用 pthreads-win32 我想…
编辑 1： 我听说这是完全不可能的，因为 libdispatch （以某种方式）依赖于 kqueue，但无法使用在 Windows 上……有人知道这是真的吗？
I’m looking into multithreading, and GCD seems like a much better option than manually writing a solution using pthread.h and pthreads-win32. However, although it looks like libdispatch is either working on, or soon going to be working on, most newer POSIX-compatible systems… I have to ask, what about Windows? What are the chances of libdispatch being ported to Windows? What are the barriers preventing that from happening?
If it came down to it, what would I need to do to preform that portage?
Edit: Some things I already know, to get the discussion started:
- We need a blocks-compatible compiler that will compile on Windows, no? Will PLBlocks handle that?
- Can we use the LLVM blocks runtime?
- Can’t we replace all the
pthread.hdependencies in userspacelibdispatchwith APR calls, for portability? Or, alternatively, usepthreads-win32I suppose…
Edit 1: I am hearing that this is completely and totally impossible, ever, because libdispatch depends (somehow) on kqueue, which can’t be made available on Windows… does anybody know if this is true?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
看一下：http://opensource.mlba-team.de/xdispatch/
该项目（和其他第三方库）将 libdispatch 引入除 macosx 之外的平台（windows、linux）
Take a look at : http://opensource.mlba-team.de/xdispatch/
This project (and other third-party libs) brings libdispatch into platforms(windows, linux) other than macosx
https://github.com/DrPizza/libdispatch
https://github.com/DrPizza/libdispatch
从我对它的基本理解来看，libdispatch 的 Windows 等效项是 非托管代码的并发运行时和a统称为托管代码的并行扩展的技术集合。在我看来，GCD 很好地映射了这两者，因为它们都以类似的方式抽象工作单元（或“任务”）。
The Windows equivalent of libdispatch, from my basic understanding of it, is the Concurrency Runtime for unmanaged code and a collection of technologies collectively known as Parallel Extensions for managed code. It appears to me that GCD maps pretty well to both of these, since they both abstract work units (or "tasks") in a similar way.
从一些研究来看，人们似乎已经对某个端口产生了相当多的兴趣，但是该端口将是一项相当艰巨的任务，并且最终可能基本上只是 API 的另一个实现，并且实际上并不与原始版本共享重要代码libdispatch.lib 调度。我确实看到了一些将 libdispatch 移植到基于 Apache Portable Runtime 而不是 POSIX 的建议，这将使其更容易跨平台到 Windows，但即使这也不是一个容易的改变。
很可能，这绝不是一项小任务。
From a bit of research, it appears that there's already a fair bit of interest in a port, but that port would be a fairly drastic undertaking and might end up being basically just another implementation of the API and not actually sharing significant code with the original libdispatch. I did see some proposals to porting libdispatch to being based on the Apache Portable Runtime instead of POSIX which'd make it easier to make it cross-platform to Windows, but even this would not be an easy change.
Likely, this would be by no means a small undertaking.
我认为直接在 Win32 上实现 libdispatch 可能比 libdispatch-on-pthreads 和 pthreads-on-Win32 或者 libdispatch-on-APR 和 APR-on-Win32 更好msdn.microsoft.com/en-us/library/ms686766(VS.85).aspx" rel="nofollow noreferrer">线程池 API。好消息是，这两个 API 非常相似，您可以自己进行移植。坏消息是，可能会存在很多极端情况，其中存在小的语义不匹配，导致难以实现精确的行为。
I think that rather than libdispatch-on-pthreads and pthreads-on-Win32, or libdispatch-on-APR and APR-on-Win32, it might be better to implement libdispatch directly on the Win32 Thread Pool API. The good news is that the two APIs are similar enough that you could probably do the port yourself. The bad news is that there would probably be lots of corner cases where there are small semantic mismatches that make exact behavior hard to achieve.