我正在阅读一些 Lua 书籍，并且正在考虑将一些遗留的（并且写得不好的）C 代码迁移到 Lua 和 C 的混合体中。
然而，这个遗留代码使用线程来处理一些关键任务（基本上是音频/视频流），而有些简单的任务也需要一些关注（用户界面）。根据我的阅读，Lua 不直接支持线程，它促进了协程的使用。
在这种情况下迁移到基于协程的环境是否明智？在我看来，我可以想象一个调度程序，它总是在每次尝试恢复最不重要的协程之间首先尝试恢复高优先级协程。因为我没有这方面的经验，所以我在这里问。
编辑
尼可波拉斯询问了更多细节。
这是一个实时应用程序。我不能承受很大的延迟来处理某些事件，例如准备好处理的新视频帧。之前的 C 程序使用线程和回调来执行此操作。例如，在出现新帧时，会调用回调并准备数据以进行处理（回调作为生产者，视频线程作为消费）。
我还没有考虑如何处理回调（也许我会用 C 保留它们并使用一些互斥锁来更新 Lua 代码的数据），但我怀疑这种设置是否使用提到的工具，适用于此类问题，如果有人有一些示例或故事并想分享。
您可能可以这样做；据我所知，您的主要挑战将是决定您可以放弃的最小时间段以及如何保证不超过这段时间。
例如，假设您的流媒体可以容忍长达 10 毫秒的延迟。这意味着您的 UI 操作必须分成不超过 10 毫秒的块。如果你恢复你的 UI 协程在文件中进行搜索并且你需要读取一个文件并且它变得很大并且读取时间超过了 10 毫秒怎么办？在您的 UI 协程将控制权交还给调度程序之前，您的流式协同程序不会获得控制权，然后调度程序会恢复您的流式协同程序。这仅意味着您需要非常小心地考虑您的 UI 可以执行的所有操作以及如何保证所有操作都遵守您为它们设置的时间限制。
在抢占式多任务处理中，调度程序会处理这一点（但它有其自身的缺点），但在协程的情况下，您的 UI 逻辑需要处理它。有一些具有类似逻辑的 lua 库（例如，copas 所做的事情接近于使用超时的套接字可能需要的东西）。
比较回调和协程，我开始越来越喜欢协程方法。它们的功能可能是相同的，但是基于协程的代码比基于回调的代码更容易阅读（并且在许多情况下更容易编写）（严格来说，在我看来）。
你没有理由不试试这个。游戏是创建一个适当的调度程序，并确保您的任何例程都不会花费太多时间才能完成。
这将有多难取决于您的代码，但调度程序可能非常简单——通过优先级或简单的计时器（如果上次运行重要的例程大于 N 毫秒，则运行重要的例程）。
yield 有一些优势，它确实使同步变得容易。
简单地说，你应该证明它，看看它是否对你足够有效。稍微玩一下，你应该很快就知道这是否真的适合你，从它的声音来看，你的调度程序可能不是很复杂。没有理由让它成为通用的，保持简单并专注于你正在做的任务，然后你循环“通用”，或者从操作系统教科书中拉出一些随机调度程序。