共 4 篇相关文章
这篇讲的是协程并发模型在真实项目中的“两面性”。作者以一个Python项目为例，分享了使用gevent协程后的编程体验：它让并发模型变得简洁，一个协程对应一个任务，抛弃了传统的线程池。但文章重点剖析了在CPU资源受限的单核环境下，协程暴露的一系列生产陷阱。 文中指出的陷阱非常具体：协程中的间接死循环会导致其他协程被饿死；引入了未被“green化”的阻塞库（如MySQL-python）会阻塞整个事件循环，导致调度延迟；在单核CPU被压榨到80%-90%时，无法设定优先级的协程库会使高时延敏感的API协程与耗时任务协程争夺资源，影响服务质量。此外，程序员在自动切换环境下容易忽略协程挂起（如长时间sleep）对整个协程池吞吐量的影响。 作者最终的实践是，为了规避CPU瓶颈，项目还是演进到了多进程结构。文章总结道，协程在低CPU系统中能带来编程简便性，但当系统负载上去后，其资源管理和调试的复杂度可能会抵消甚至超过多线程模型。对于考虑引入协程的开发者而言，这篇经验分享提前点明了从理论便利走向工程现实时需要应对的挑战。
这篇讲的是 Skynet 框架如何利用 Lua 协程，将基于回调的消息处理模型，巧妙地转换为开发者更熟悉的阻塞式 RPC 调用风格。 Skynet 本身是一个消息分发器，每个服务通过一个统一的回调函数处理消息。这种异步模型虽然高效，但写起来可能不够直观。文章深入剖析了框架内部的核心技巧：为每条进入的消息创建一个协程，并让消息处理函数运行在其中。当遇到如网络请求等需要阻塞的操作时，处理函数会通过 coroutine.yield 将控制权交还框架，并附带操作类型（如“CALL”）和会话ID。框架挂起该协程，等待结果消息到达后，再根据会话ID找到并恢复对应的协程继续执行。 文章还进一步探讨了更高级的场景：如果开发者想在消息处理中自己使用协程怎么办？此时，用户协程的 yield 会被自己的 resume 捕获，导致 Skynet 的阻塞 API 失效。为此，框架提供了 skynet.coroutine 库。它在用户 yield 的类型前加上一个“USER”标记，从而与框架的内部 yield 区分开来，确保两者能协同工作而不冲突。 作者最后分享了使用协程作为迭代器的实际案例：处理一个巨大的内存操作日志文件时，通过协程实现了流式读取和转换，避免了内存溢出，展示了这一机制在实际工程中的实用价值。
这篇讲的是如何用不到100行代码在C语言里实现协程。作者从协程的背景讲起，对比了它和线程在“生产者-消费者”模型中的差异，指出C语言由于依赖栈帧实现函数调用，缺乏原生yield语义，直接实现对称协程比较麻烦。 文章核心介绍了开源库protothreads。这个库“蝇量级”到所有代码都在5个头文件里，每个协程只需2字节内存开销，非常适合资源敏感的嵌入式场景。作者还追溯了作者Adam Dunkels的其他知名作品，暗示其工业级可靠性。 实现的关键在于一个C语言“奇技淫巧”：利用switch-case语句的穿透特性和`__LINE__`宏，模拟了程序计数器的保存与恢复。通过将return语句嵌入case标签，并在函数入口用一个switch跳转到上次的挂起点，就用纯C语法实现了协程的挂起与恢复。文章最后展示了如何用宏封装出Begin/Yield/End这样的简洁接口，让开发者能写出类似Python生成器的代码结构。
这篇讲的是Lua语言中的协程（coroutine）机制。作者从实际开发中遇到的并发处理挑战出发，详细拆解了Lua协程的实现原理和核心优势。Lua协程采用非对称设计，基于独立栈空间管理状态，切换时仅需保存少量上下文，因此比操作系统线程更轻量级，资源开销极小。 文章将Lua协程与Go的goroutine、Python的asyncio等模型进行了对比：goroutine依赖运行时自动调度，适合高吞吐量场景；而Lua协程需要通过显式的yield和resume调用来切换，提供了更精细的控制流，适合I/O密集型或需要精确协调的任务。作者强调，Lua协程在游戏服务器、网络代理等应用中表现突出，能够高效处理数万个并发连接，其巧妙之处在于用最小成本实现了协作式多任务，但这也要求开发者主动管理调度逻辑，避免阻塞。 通过源码层面的分析，文章指出Lua协程的栈式结构和状态保存机制是其高效的关键。最终结论是，Lua协程是解决特定并发问题的优雅工具，尤其适合对性能和控制有较高要求的嵌入式或实时系统环境。
