问题标签 [grand-central-dispatch]

在我的应用程序中，我将CFMachPortRef（通过CFMachPortCreateRunLoopSource）添加到线程CFRunLoop

现在我在问自己，这可以使用 GCD 完成吗？假设不是生成我自己的NSThread并通过CFRunLoopAddSource将创建的CFRunLoopSourceRef添加到其运行循环中，而是将事件端口添加到调度的运行循环中？

我认为由于 GCD 的内部工作原理，这很可能不起作用，但我真的不知道。

更新

到目前为止我得到了这个，但是事件点击的回调函数和 dispatch_source_event_handler 块都没有被调用。有任何想法吗？

我查看了 WWDC 2010 的一些演示文稿，还阅读了大部分关于块和并发的文档，并且有几个关于在 Grand Central Dispatch 中使用带有串行队列的块的问题。我有一个 iOS 4 项目，它有一个滚动视图和一个图像信息字典——图像的 URL 等等。我想使用 GCD 和块来下载图像并将它们放在我的滚动视图中，因此不会阻塞主线程。我编写了以下似乎有效的代码：

我有两个问题：

1. 根据并发指南，我不应该从封闭范围中捕获非标量类型的变量 - 在我的代码中，我捕获 dict 这是一个 NSDictionary* 对象。如果我不允许捕获它，我应该如何编写代码？块是否仅捕获实际使用的封闭范围中的变量？

2. 如果我在通过串行调度队列获取所有图像之前离开当前的 ViewController 会发生什么？我不认为他们知道创建它们的 ViewController 已经消失了，所以当他们执行完成处理程序时会发生什么，我将图像视图插入到主线程上的滚动视图中？它会导致错误还是什么？当我的 ViewController 消失时，如何取消串行队列上的任何剩余操作？

此致，

我有一个 Cocoa 应用程序，它监听通知并将更新发布到NSMutableArray由NSCollectionView. 通知大量到达，因此我正在考虑使用不同的队列来处理它们并相应地更新数组。

现在我addObserverForName:object:queue:usingBlock用来注册通知，当我为队列NSCollectionView指定时它工作正常（数组和更新） 。[NSOperationQueue mainQueue]但是，当我创建自己的队列（使用[[NSOperationQueue alloc] init]）时，NSCollectionView停止更新。使用调试器，我可以看到它正在监视的阵列正在更新。

这是一个错误，还是我在这里错过了什么？

我有一个像这样的异步任务：

有没有办法在后台任务完成时收到通知？

或者在完成时调用一个方法？

我已经阅读了文档并查看了 dispatch_after，但它似乎更倾向于在一段时间后调度该方法。

谢谢您的帮助。

在 iOS 4.0 中通过 Grand Central Dispatch 加载图像（每个 1 个块）是个好主意吗？（用于 UITableView）

为什么 Apple 首选 runloop，如 WWDC 视频会话 207 和 208 所示？

我想知道使用像pthread_once()andsem_wait()或 dispatch_* 函数这样的 POSIX 调用会更好/更快，所以我创建了一个小测试并对结果感到惊讶（问题和结果在最后）。

在测试代​​码中，我使用 mach_absolute_time() 来计时调用。我真的不在乎这与纳秒不完全匹配。我正在将这些值相互比较，因此确切的时间单位无关紧要，只有间隔之间的差异才重要。结果部分中的数字是可重复的，不是平均的；我本可以平均时间，但我不是在寻找确切的数字。

test.m（简单的控制台应用程序；易于编译）：

在我的 iMac（雪豹服务器 10.6.4）上：

我得到：

在我的 MacbookPro（雪豹 10.6.4）上：

我有：

在 iPhone 3GS 4.0.2 上，我得到：

问题和陈述：

• sem_wait()并且sem_post()在没有争用时很慢
  • 为什么会这样？
  • OSX 不关心兼容的 API 吗？是否有一些遗留代码迫使它变慢？
  • 为什么这些数字与 dispatch_semaphore 函数不同？
• sem_wait()并且sem_post()在争用时和不在争用时一样慢（存在差异，但我认为在争用和非争用之间会有巨大差异；我期望像 dispatch_semaphore 代码中那样的数字）
• sem_wait()并且sem_post()在使用命名信号量时速度较慢。
  • 为什么？这是因为信号量必须在进程之间同步吗？这样做可能会有更多的包袱。
• dispatch_semaphore_wait()并且dispatch_semaphore_signal()在没有争议的情况下很快就会发疯（这并不奇怪，因为苹果经常吹捧这一点）。
• dispatch_semaphore_wait()并且dispatch_semaphore_signal()比竞争时 sem_wait()慢3 倍sem_post()
  • 为什么这么慢？这对我来说没有意义。我本来希望这与争论中的 sem_t 相提并论。
• dispatch_once()比 快pthread_once()，大约 10 倍，为什么？我从标题中唯一能看出的是 withdispatch_once()比 with没有函数调用负担pthread_once()。

动机： 我得到了两套工具来完成信号量或一次调用的工作（实际上我同时发现了其他信号量变体，但除非作为更好的选择提出，否则我会忽略它们）。我只是想知道什么是最适合这项工作的工具（如果您可以选择用飞利浦或平头螺丝拧入螺丝，如果我不必拧紧螺丝和平头，我会选择飞利浦）拧紧螺丝）。看来，如果我开始使用 libdispatch 编写实用程序，我可能无法将它们移植到其他还没有 libdispatch 工作的操作系统……但使用起来非常诱人；）

就目前而言：当我不必担心可移植性和 POSIX 调用时，我将使用 libdispatch。

谢谢！

我有一个需要将数据（使用 POST）发送到服务器的应用程序。此功能必须在 NavigationController 子控制器之一上，并且用户应该能够离开此控制器和/或关闭应用程序（仅支持 iPhone4/iOS4）。我应该使用线程/NSOperations 或/和使用现有的异步方法发送数据吗？任何想法/最佳实践如何实现这一点？

我一直在编写一些代码来替换一些现有的：

套接字读取代码。我想将其更改为使用 GCD 队列，以便我可以使用 dispatch_async 将事件弹出到队列中，而不是维护“必须在下一次迭代时调用”数组。我也已经在使用 GCD 队列来 /contain/ 这个特定的操作，因此希望将其转移到更自然的 GCD 调度形式。（不是独占串行队列的 while() 循环）

但是，当我尝试将其重构为依赖于从绑定到套接字描述符上的 DISPATCH_SOURCE_TYPE_READ 和 DISPATCH_SOURCE_TYPE_WRITE 的事件处理程序中触发的调度源的表单时，依赖于此调度的库代码停止工作。我的第一个假设是我误解了 DISPATCH_SOURCE_TYPE_READ 和 DISPATCH_SOURCE_TYPE_WRITE 的使用——我曾假设它们会产生与使用这些套接字描述符调用 select() 大致相同的行为。

我是否误解了 GCD 调度来源？或者，关于重构，我是否在不适合的情况下使用它？

假设我正在异步调度中运行一些代码。..有没有办法在它完成之前终止它创建的线程？就像用户点击取消一样

我正在尝试在后台运行一个进程以生成一个字符串，然后在主线程中使用该字符串（发送到远程服务器）。代码在模拟器中运行良好，并且字符串按预期记录了两次。

在设备（iPad、4.2 和各种 iPhone）上，每次使用 EXC_BAD_ACCESS 都会崩溃。似乎 myString 超出了范围，但这似乎与Wikipedia上使用相同原理的示例背道而驰。

代码如下：

有谁知道为什么会崩溃，以及修复它的最佳方法？

我犯了简化代码以保持我的问题清晰的错误。

在主队列上，我实际上通过另一个呼叫向自己发送消息，这会导致访问不正确。

解决方案是在我的异步队列上调用该方法，并在方法内部将代码包装在 dispatch_async(dispatch_get_main_queue(), ^{}); 堵塞。

希望这会对其他人有所帮助。