共 4 篇相关文章
这篇文章聚焦于将基于多线程调度器的项目 `soluna`，移植到 WebAssembly 等非 Windows 平台时遇到的核心难题。作者从项目维护的实际需求出发，解释了为何在可能退化为单线程的环境中，模拟出 `ltask` 调度器的能力成为关键挑战。 文中介绍的核心实现思路颇具巧思：将原本独立的任务调度器巧妙地“嵌入”到主线程自身的消息循环里。这意味着主线程需要同时承担两份工作——既要处理自己的消息队列，又要扮演调度器的角色，为其他逻辑“线程”（通常是协程）分配执行机会。作者没有停留在理论层面，而是深入探讨了如何在单一线程上，通过协作式调度和精心设计的队列，来模拟多线程环境下的任务切换与调度行为。 这种设计确保了项目的多线程调度架构得以保留，其核心价值不因平台变化而丧失。文章清晰地展示了一个现实场景下的工程权衡与技术适配过程，对于需要处理类似跨平台移植问题，或是对单线程高并发模型感兴趣的开发者而言，提供了非常具体的实现参考。
这篇讲的是如何用 State Threads (ST) 这个仅3000行C代码的轻量级库，来终结高性能服务器开发中令人头疼的异步回调噩梦。作者从此前介绍的协程库 Protothreads 出发，引出了这个更适合服务器领域的“宝藏”项目。 文章的核心在于将 ST 与传统的事件驱动状态机（EDSM）进行对比。传统 EDSM 依赖异步回调，开发者需要将线性的处理逻辑拆解成一堆回调函数，心智负担沉重。而 ST 的巧妙之处在于，它在 EDSM 的内核之上，为每个网络连接抽象出一个“线程”概念。这个线程并非操作系统线程，而是由 ST 自己在用户空间调度的轻量级执行体。 ST 的调度器通过模拟 setjmp/longjmp 来切换这些“线程”的上下文，整个过程没有系统调用开销。只有当所有“线程”都在等待 I/O 时，才会触发一次真正的 select()/poll() 系统调用。这样，开发者可以用接近写多线程同步代码的直观方式（线性思维）来编写高性能网络程序，同时又享受事件驱动模型带来的低开销与高可扩展性，避免了回调割裂逻辑的复杂性。 文章还梳理了 ST 从网景、SGI 到 Yahoo! 的发展历史，并讨论了其 MPL/GPL 双许可证的兼容性细节。尽管这个库已稳定多年未再更新，但其“结合多线程编程简洁性与事件驱动性能”的设计思想，至今仍对理解服务器编程模型有重要启发。
这篇从一道看似简单的代码题入手：当`setTimeout`的延迟设为0毫秒时，回调是否立即执行？作者指出，实际行为并非立即执行，而是将任务放入队列，这引出了对JavaScript单线程本质和浏览器内核多线程协作的探讨。 文章重点梳理了浏览器内核中的关键线程，包括JavaScript引擎线程、界面渲染线程和事件触发线程，并解释了它们之间的互动关系。核心观点在于，JavaScript引擎线程与浏览器渲染线程是互斥的——脚本执行时渲染会挂起，这直接影响了页面性能和加载策略。文中通过图解和概念分析，澄清了定时器、异步事件（如点击、Ajax请求）是如何通过事件队列与单线程的引擎交互的。 作者最后还解答了“单线程如何处理异步请求”的疑问，明确了异步操作实际由浏览器新线程处理，结果再回调入队列。整篇文章将理论机制与日常编码场景结合，帮助开发者理解代码背后的执行逻辑。
这篇讲的是浏览器执行JavaScript代码时一个常被忽略但至关重要的底层事实：JS引擎与浏览器UI渲染共享同一个主线程。作者从事件循环模型出发，解释了所有用户操作（如点击）、页面渲染和Ajax回调等任务，都会被排入同一个队列。 文章核心在于点明这个机制带来的直接后果：由于是单线程顺序执行，如果一段JavaScript代码运行时间过长，它会独占主线程，导致后续任务堆积，界面无法响应用户的其他交互，从而出现卡顿甚至无响应的状况。这实际上解释了为什么耗时计算或复杂渲染会“冻结”页面。 对前端开发者而言，理解这个限制意义重大。它强调了编写高效、短时运行代码的必要性，也引出了Web Worker等利用多线程进行耗时计算的技术方案的价值。这篇文章帮助你从根源上看懂浏览器行为的逻辑，为性能优化打下认知基础。
