如何在iOS上实现协同路由 我正在把一个C++项目移植到iOS上，用于iPhone和iPad。该项目广泛使用Boost.Coroutine库。Coroutine没有针对iPhone的ARMv6/ARMv7指令集的实现

是否有其他可以在iOS上运行的协同程序库

如果没有，是否可以在ARM上编写协同程序行为？我可以看到一些可能的方法：

• 直接编写汇编指令以执行堆栈操作。我不太精通汇编，我担心ARM架构可能不包括复制和粘贴堆栈或手动移动堆栈指针所需的指令
• 使用类似于pthreads或Win32光纤的东西编写协同路由。我不确定是否有类似的东西可以在iOS上使用
• 在线程之上实现协同路由，甚至可能是Boost.Coroutine本身。这似乎最有可能奏效，但肯定会有性能缺陷

---

注意：Unity支持iOS上C#中的协同程序；我不确定这是否仅限于典型协同程序行为的一个较小子集。如果没有，这是否意味着Unity有了解决方案？

您几乎肯定不想编写汇编指令来执行堆栈操作。iOS已经是ARM指令集的第三个版本，已经从ARMv6到ARMv7过渡到ARMv7s。从iPhone5开始，苹果进一步增加了一个人为的障碍，即你不能提交一个带有同样支持iPhone5全屏幕的ARMv6 fork的应用程序。我相信苹果的动机是确保它在将来的某个时候可以过渡到没有ARMv6兼容模式的处理器，但对我们开发者来说，这显然意味着不要过于依赖特定的指令集

那就剩下线了。iOS有一整套开发良好的线程机制，pthread可以公开相关的子集。Grand Central Dispatch往往是现在使用的正常解决方案，以确保不同的任务可以同时发生，因此吞噬了大部分Internet文档，但较低级别的解决方案仍然存在

显而易见的简单示例，使用：

---

boost.coroutine（来自Oliver Kowalke；上个月来自boost社区）使用了boost.context，它支持ARMv6（ARM Cortext Ax）

您能谈谈您希望协作的特定模式吗？除了一个简单的答案之外，能够说出这样的话是很有帮助的，比如“很难做Y的原因是正常模式是X”。协同程序通常是个坏主意——可怜的人的多任务处理。而且，您可以使用iOS调度队列完成大部分相同的功能。（请记住，弄脏调用堆栈是非常危险的。）@Hot-Licks协同程序非常有用，可以在一种语言中使用它们（或更强大的功能，如continuations），而且它们不是穷人的多任务处理能力。以单线程生产者/消费者为例——它可以自然地用协程表示，多线程版本同样需要锁。状态机是另一个常见的例子。如果协同程序是个坏主意，那么为什么许多现代语言都内置了对它们的支持呢？为什么人们在没有这种支持的情况下（从C到C）为语言实现它们？调度队列很好，但与此无关。有些语言，例如那些实现“continuations”的语言，需要类似于协程的东西，但大多数语言不需要。至于生产者/消费者，让我向您保证，在现代操作系统上，协同程序版本将比多线程版本复杂得多（并且几乎肯定需要锁来防止操作系统的破坏性干扰）。我曾经开始在一个光秃秃的PalmIV微型机上实现一个协同路由方案，但最终发现一个非先发制人的任务分配方案更干净。这是IBM 5100的经典生产者/消费者磁带复制实用程序。@Tommy协同程序主要用于RPC库的此项目。为了从原始项目中获得持续的修复和改进，我希望我的解决方案尽可能与源代码实现类似。i、 如果我必须重写他们的RPC库而不使用协同路由，我会的，但我想先彻底研究一下在iOS上实现协同路由的选项。

- (void)methodOnThread1
{
    while(1)
    {
        [conditionLock lockWhenCondition:kMoreInputAvailable];

        // process whatever is currently in the common access pool

        [conditionLock unlockWithCondition:kWaitingForInput];
    }
}

- (void)methodOnThread2
{
    while(1)
    {
         // do whatever is necessary to produce more input,
         // creating it locally and taking as long as it takes


        [conditionLock lockWhenCondition:kWaitingForInput];

        // push input to common access pool, by whatever means

        [conditionLock unlockWithCondition:kMoreInputAvailable];
    }
}