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