尧图网页设计 
Effect 4 进程保活机制重构移除 Fiber 级 keep-alive统一由Runtime.makeRunMain维持进程生命周期【免费下载链接】effectBuild production-ready applications in TypeScript项目地址: https://gitcode.com/GitHub_Trending/ef/effect本文深入剖析 Effect 仓库 pre-release 变更集 .changeset/pre/lazy-timers-exist.md 所记录的运行时架构调整Effect 4 移除了 Fiber 级的 keep-alive 定时器改为在Runtime.makeRunMain中统一以长间隔定时器维持宿主进程存活。通过阅读本文你将理解该变更的动机、makeRunMain的底层实现细节、平台层runMain与它的协作关系以及这一演进对日常编写 Effect 应用的实际影响。变更集解读一行描述背后的架构决策变更集正文只有一句话却是一次关键的运行时行为调整--- effect: patch --- Remove fiber-level keep-alive intervals and keep the process alive from Runtime.makeRunMain instead.拆解这句话包含三个信息点移除对象此前实现中为每个需要保活的 Fiber 单独安装的setIntervalkeep-alive 定时器fiber-level keep-alive intervals。替代方案进程保活职责上移到Runtime.makeRunMain即程序主入口运行器这一层统一承担。版本影响标记为patch属于行为修正而非破坏性 API 变更但对运行时语义有实际影响。要理解这次重构的价值需要先回顾 Effect 3 时代Fiber 挂起导致进程提前退出的问题这正是 migration/fiber-keep-alive.md 记录的迁移背景。问题背景v3 中异步挂起会让进程提前退出在 v3 中核心effect运行时不会因为 Fiber 处于挂起状态而保活 Node.js 进程。当一个 Fiber 等待Deferred.await之类的异步操作、而事件循环上没有其他待执行任务时Node.js 会认为工作已结束进程立即退出——Fiber 的挂起在 Node 看来并不算待办工作。import { Deferred, Effect } from effect const program Effect.gen(function*() { const deferred yield* Deferred.makestring() yield* Deferred.await(deferred) // 挂起等待v3 下进程可能直接退出 }) Effect.runPromise(program)v3 时代的唯一规避手段是改用平台包提供的runMain它内部安装一个长期存活的setInterval定时器把进程钉住直到根 Fiber 完成import { NodeRuntime } from effect/platform-node NodeRuntime.runMain(program)这套方案的问题在于保活逻辑寄生在平台层核心运行时本身不感知进程生命周期任何直接使用Effect.runPromise/Effect.runFork的代码都可能踩到程序莫名退出的坑。v4 的核心变更保活内置进核心运行时v4 将 keep-alive 机制内置到核心运行时。当前仓库中这一能力集中在 packages/effect/src/Runtime.ts 的makeRunMain实现里。其核心逻辑如下已节选关键部分export const makeRunMain ( f: E, A(options: { readonly fiber: Fiber.FiberA, E readonly teardown: Teardown }) void ) dual((args) Effect.isEffect(args[0]), (effect, options?) { const fiber options?.disableErrorReporting true ? Effect.runFork(effect) : Effect.runFork( Effect.tapCause(effect, (cause) { if (Cause.hasInterruptsOnly(cause)) return Effect.void const isReported getErrorReported(Cause.squash(cause)) return isReported ? Effect.logError(cause) : Effect.void }) ) try { const keepAlive globalThis.setInterval(constVoid, 2_147_483_647) fiber.addObserver(() { clearInterval(keepAlive) }) } catch {} const teardown options?.teardown ?? defaultTeardown return f({ fiber, teardown }) })这段实现揭示了几个值得注意的工程细节1. 用最大可调度间隔代替长期存活定时器2_147_483_647是 32 位有符号整数的最大值也是setInterval/setTimeout允许的最大延迟毫秒数约 24.8 天。以constVoid空函数为回调、以该值为间隔注册定时器等价于只要定时器不被清除事件循环就永远有活干从而保证宿主进程不会因为事件循环空转而退出。2. 定时器的生命周期与根 Fiber 严格绑定fiber.addObserver(() clearInterval(keepAlive))保证根 Fiber 一旦完成无论成功、失败还是被中断keep-alive 定时器立即清除进程可以自然结束。这避免了旧方案中定时器泄漏、进程永远不退出的副作用。3. try/catch 兜底兼容屏蔽定时器的宿主环境try { ... } catch {}并非空壳。文档注释Runtime.ts明确说明如果宿主环境屏蔽了定时器 APIrunner 仍然可以启动只是无法使用该 keep-alive 兜底方案。这一保护在变更集中虽然未展开但可以从 packages/effect/CHANGELOG.md 中找到其演进痕迹。演进脉络三次提交逐步收敛保活方案从 packages/effect/CHANGELOG.md 的 release note 可以还原这次重构的完整演进路径它并非一步到位提交变更内容解决的问题#1418为 keepAlive 的setInterval/clearInterval加保护使Effect.runPromise在屏蔽定时器 API 的运行时中也能工作部分宿主环境如部分测试框架、特殊运行时会禁用定时器直接调用会抛错#1452让 Fiber 级 keepAlive 的setInterval求值变为惰性lazy避免每个 Fiber 在创建时无条件安装定时器带来的开销#1579移除 Fiber 级 keep-alive 定时器改为由Runtime.makeRunMain统一保活进程将保活职责上收消除每 Fiber 一定时器的冗余与泄漏风险从每个需要保活的 Fiber 各自安装定时器到主入口运行器统一安装一个定时器本质上是一次从分散式保活到集中式保活的重构定时器数量从 O(活跃 Fiber 数) 降为 O(1)并且与程序根 Fiber的生命周期天然对齐——进程的存续本来就应该与主程序的生命周期一致而不是与任意子 Fiber 的挂起状态绑定。顺带说明搜索当前仓库源码可以发现keepAlive标识符如今只残留在unstable/cluster与unstable/reactivity等高级模块如Entity.keepAlive、Atom.keepAlive这些是业务语义层面的实体保活与本次移除的Fiber 级进程保活定时器是两回事不要混淆。平台层如何依托makeRunMain以 Node 为例核心运行时提供makeRunMain后各平台适配层只需基于它注入平台特定的信号处理与退出逻辑。以 Node 为例调用链为NodeRuntime.runMainpackages/platform/node/src/NodeRuntime.ts→effect/platform-node-shared的共享实现packages/platform/node-shared/src/NodeRuntime.ts→Runtime.makeRunMain其中共享实现的关键代码export const runMain: ... Runtime.makeRunMain(({ fiber, teardown }) { let receivedSignal false fiber.addObserver((exit) { process.removeListener(SIGINT, onSigint) process.removeListener(SIGTERM, onSigint) teardown(exit, (code) { if (receivedSignal || code ! 0) { process.exit(code) } }) }) function onSigint() { receivedSignal true fiber.interruptUnsafe(fiber.id) } process.on(SIGINT, onSigint) process.on(SIGTERM, onSigint) })可以看到分层协作关系非常清晰makeRunMain负责fork 根 Fiber、安装并维护 keep-alive 定时器、默认错误上报disableErrorReporting可关闭、把{ fiber, teardown }交给平台回调。平台层负责注册SIGINT/SIGTERM监听、收到信号后调用fiber.interruptUnsafe优雅中断根 Fiber、Fiber 完成时移除信号监听并依据 teardown 决定是否process.exit(code)。这种分层意味着任何新平台Bun、Deno、Worker 等只要实现自己的信号处理与退出策略就能免费获得核心运行时的进程保活能力无需重复实现定时器逻辑。配套机制teardown 与退出码makeRunMain的另一个配套组件是defaultTeardownRuntime.ts它定义了主程序完成后的退出码规则成功完成 →0仅含中断interruptions的失败 →130对应 CtrlC 的常规退出码其他失败 → 若 squashed 错误上带有errorExitCode标记则取其值否则1混合 Cause既有中断又有其他失败时走 squashed error 路径而非130。开发者还可以通过自定义teardown选项覆盖默认行为或给错误类挂载Runtime.errorExitCode标记来自定义失败退出码。对应用开发者的影响与建议这次变更对日常开发者的实际影响可以总结为三点Effect.runPromise与runMain的行为趋于一致保活不再依赖平台层的runMain直接runPromise一个挂起在Deferred.await等操作上的程序进程也能保持存活前提是宿主环境未屏蔽定时器 API。runMain依然是推荐入口如 migration/fiber-keep-alive.md 所述平台runMain额外提供信号处理SIGINT/SIGTERM优雅中断、退出码管理与错误上报这些是裸runPromise不具备的。资源管理更干净保活定时器与根 Fiber 完成事件绑定程序结束即清理不再有 Fiber 级定时器累积带来的潜在资源泄漏。对于从 v3 迁移的开发者migration/fiber-keep-alive.md 提供了完整的背景说明若你的应用此前依赖平台 runMain 安装定时器保活这一隐式行为升级到 v4 后无需任何改动即可获得等价甚至更优的保活能力。小结本次变更集记录的是一次典型的职责上收式重构将散落在 Fiber 层的进程保活定时器收拢到Runtime.makeRunMain单一入口统一管理。从 Runtime.ts 的实现可以看到setInterval(constVoid, 2_147_483_647)配合根 Fiber 观察者清理构成了一个 O(1) 开销、生命周期严格对齐、对屏蔽定时器的宿主环境友好的保活方案而 NodeRuntime.ts 则展示了平台层如何在其之上叠加信号处理与退出码管理。理解这一机制有助于你在编写长时间运行、大量异步挂起的 Effect 应用时对进程生命周期有更准确的预期与控制。【免费下载链接】effectBuild production-ready applications in TypeScript项目地址: https://gitcode.com/GitHub_Trending/ef/effect创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Effect 4 进程保活机制重构：移除 Fiber 级 keep-alive，统一由 `Runtime.makeRunMain` 维持进程生命周期
Effect 4 进程保活机制重构移除 Fiber 级 keep-alive统一由Runtime.makeRunMain维持进程生命周期【免费下载链接】effectBuild production-ready applications in TypeScript项目地址: https://gitcode.com/GitHub_Trending/ef/effect本文深入剖析 Effect 仓库 pre-release 变更集 .changeset/pre/lazy-timers-exist.md 所记录的运行时架构调整Effect 4 移除了 Fiber 级的 keep-alive 定时器改为在Runtime.makeRunMain中统一以长间隔定时器维持宿主进程存活。通过阅读本文你将理解该变更的动机、makeRunMain的底层实现细节、平台层runMain与它的协作关系以及这一演进对日常编写 Effect 应用的实际影响。变更集解读一行描述背后的架构决策变更集正文只有一句话却是一次关键的运行时行为调整--- effect: patch --- Remove fiber-level keep-alive intervals and keep the process alive from Runtime.makeRunMain instead.拆解这句话包含三个信息点移除对象此前实现中为每个需要保活的 Fiber 单独安装的setIntervalkeep-alive 定时器fiber-level keep-alive intervals。替代方案进程保活职责上移到Runtime.makeRunMain即程序主入口运行器这一层统一承担。版本影响标记为patch属于行为修正而非破坏性 API 变更但对运行时语义有实际影响。要理解这次重构的价值需要先回顾 Effect 3 时代Fiber 挂起导致进程提前退出的问题这正是 migration/fiber-keep-alive.md 记录的迁移背景。问题背景v3 中异步挂起会让进程提前退出在 v3 中核心effect运行时不会因为 Fiber 处于挂起状态而保活 Node.js 进程。当一个 Fiber 等待Deferred.await之类的异步操作、而事件循环上没有其他待执行任务时Node.js 会认为工作已结束进程立即退出——Fiber 的挂起在 Node 看来并不算待办工作。import { Deferred, Effect } from effect const program Effect.gen(function*() { const deferred yield* Deferred.makestring() yield* Deferred.await(deferred) // 挂起等待v3 下进程可能直接退出 }) Effect.runPromise(program)v3 时代的唯一规避手段是改用平台包提供的runMain它内部安装一个长期存活的setInterval定时器把进程钉住直到根 Fiber 完成import { NodeRuntime } from effect/platform-node NodeRuntime.runMain(program)这套方案的问题在于保活逻辑寄生在平台层核心运行时本身不感知进程生命周期任何直接使用Effect.runPromise/Effect.runFork的代码都可能踩到程序莫名退出的坑。v4 的核心变更保活内置进核心运行时v4 将 keep-alive 机制内置到核心运行时。当前仓库中这一能力集中在 packages/effect/src/Runtime.ts 的makeRunMain实现里。其核心逻辑如下已节选关键部分export const makeRunMain ( f: E, A(options: { readonly fiber: Fiber.FiberA, E readonly teardown: Teardown }) void ) dual((args) Effect.isEffect(args[0]), (effect, options?) { const fiber options?.disableErrorReporting true ? Effect.runFork(effect) : Effect.runFork( Effect.tapCause(effect, (cause) { if (Cause.hasInterruptsOnly(cause)) return Effect.void const isReported getErrorReported(Cause.squash(cause)) return isReported ? Effect.logError(cause) : Effect.void }) ) try { const keepAlive globalThis.setInterval(constVoid, 2_147_483_647) fiber.addObserver(() { clearInterval(keepAlive) }) } catch {} const teardown options?.teardown ?? defaultTeardown return f({ fiber, teardown }) })这段实现揭示了几个值得注意的工程细节1. 用最大可调度间隔代替长期存活定时器2_147_483_647是 32 位有符号整数的最大值也是setInterval/setTimeout允许的最大延迟毫秒数约 24.8 天。以constVoid空函数为回调、以该值为间隔注册定时器等价于只要定时器不被清除事件循环就永远有活干从而保证宿主进程不会因为事件循环空转而退出。2. 定时器的生命周期与根 Fiber 严格绑定fiber.addObserver(() clearInterval(keepAlive))保证根 Fiber 一旦完成无论成功、失败还是被中断keep-alive 定时器立即清除进程可以自然结束。这避免了旧方案中定时器泄漏、进程永远不退出的副作用。3. try/catch 兜底兼容屏蔽定时器的宿主环境try { ... } catch {}并非空壳。文档注释Runtime.ts明确说明如果宿主环境屏蔽了定时器 APIrunner 仍然可以启动只是无法使用该 keep-alive 兜底方案。这一保护在变更集中虽然未展开但可以从 packages/effect/CHANGELOG.md 中找到其演进痕迹。演进脉络三次提交逐步收敛保活方案从 packages/effect/CHANGELOG.md 的 release note 可以还原这次重构的完整演进路径它并非一步到位提交变更内容解决的问题#1418为 keepAlive 的setInterval/clearInterval加保护使Effect.runPromise在屏蔽定时器 API 的运行时中也能工作部分宿主环境如部分测试框架、特殊运行时会禁用定时器直接调用会抛错#1452让 Fiber 级 keepAlive 的setInterval求值变为惰性lazy避免每个 Fiber 在创建时无条件安装定时器带来的开销#1579移除 Fiber 级 keep-alive 定时器改为由Runtime.makeRunMain统一保活进程将保活职责上收消除每 Fiber 一定时器的冗余与泄漏风险从每个需要保活的 Fiber 各自安装定时器到主入口运行器统一安装一个定时器本质上是一次从分散式保活到集中式保活的重构定时器数量从 O(活跃 Fiber 数) 降为 O(1)并且与程序根 Fiber的生命周期天然对齐——进程的存续本来就应该与主程序的生命周期一致而不是与任意子 Fiber 的挂起状态绑定。顺带说明搜索当前仓库源码可以发现keepAlive标识符如今只残留在unstable/cluster与unstable/reactivity等高级模块如Entity.keepAlive、Atom.keepAlive这些是业务语义层面的实体保活与本次移除的Fiber 级进程保活定时器是两回事不要混淆。平台层如何依托makeRunMain以 Node 为例核心运行时提供makeRunMain后各平台适配层只需基于它注入平台特定的信号处理与退出逻辑。以 Node 为例调用链为NodeRuntime.runMainpackages/platform/node/src/NodeRuntime.ts→effect/platform-node-shared的共享实现packages/platform/node-shared/src/NodeRuntime.ts→Runtime.makeRunMain其中共享实现的关键代码export const runMain: ... Runtime.makeRunMain(({ fiber, teardown }) { let receivedSignal false fiber.addObserver((exit) { process.removeListener(SIGINT, onSigint) process.removeListener(SIGTERM, onSigint) teardown(exit, (code) { if (receivedSignal || code ! 0) { process.exit(code) } }) }) function onSigint() { receivedSignal true fiber.interruptUnsafe(fiber.id) } process.on(SIGINT, onSigint) process.on(SIGTERM, onSigint) })可以看到分层协作关系非常清晰makeRunMain负责fork 根 Fiber、安装并维护 keep-alive 定时器、默认错误上报disableErrorReporting可关闭、把{ fiber, teardown }交给平台回调。平台层负责注册SIGINT/SIGTERM监听、收到信号后调用fiber.interruptUnsafe优雅中断根 Fiber、Fiber 完成时移除信号监听并依据 teardown 决定是否process.exit(code)。这种分层意味着任何新平台Bun、Deno、Worker 等只要实现自己的信号处理与退出策略就能免费获得核心运行时的进程保活能力无需重复实现定时器逻辑。配套机制teardown 与退出码makeRunMain的另一个配套组件是defaultTeardownRuntime.ts它定义了主程序完成后的退出码规则成功完成 →0仅含中断interruptions的失败 →130对应 CtrlC 的常规退出码其他失败 → 若 squashed 错误上带有errorExitCode标记则取其值否则1混合 Cause既有中断又有其他失败时走 squashed error 路径而非130。开发者还可以通过自定义teardown选项覆盖默认行为或给错误类挂载Runtime.errorExitCode标记来自定义失败退出码。对应用开发者的影响与建议这次变更对日常开发者的实际影响可以总结为三点Effect.runPromise与runMain的行为趋于一致保活不再依赖平台层的runMain直接runPromise一个挂起在Deferred.await等操作上的程序进程也能保持存活前提是宿主环境未屏蔽定时器 API。runMain依然是推荐入口如 migration/fiber-keep-alive.md 所述平台runMain额外提供信号处理SIGINT/SIGTERM优雅中断、退出码管理与错误上报这些是裸runPromise不具备的。资源管理更干净保活定时器与根 Fiber 完成事件绑定程序结束即清理不再有 Fiber 级定时器累积带来的潜在资源泄漏。对于从 v3 迁移的开发者migration/fiber-keep-alive.md 提供了完整的背景说明若你的应用此前依赖平台 runMain 安装定时器保活这一隐式行为升级到 v4 后无需任何改动即可获得等价甚至更优的保活能力。小结本次变更集记录的是一次典型的职责上收式重构将散落在 Fiber 层的进程保活定时器收拢到Runtime.makeRunMain单一入口统一管理。从 Runtime.ts 的实现可以看到setInterval(constVoid, 2_147_483_647)配合根 Fiber 观察者清理构成了一个 O(1) 开销、生命周期严格对齐、对屏蔽定时器的宿主环境友好的保活方案而 NodeRuntime.ts 则展示了平台层如何在其之上叠加信号处理与退出码管理。理解这一机制有助于你在编写长时间运行、大量异步挂起的 Effect 应用时对进程生命周期有更准确的预期与控制。【免费下载链接】effectBuild production-ready applications in TypeScript项目地址: https://gitcode.com/GitHub_Trending/ef/effect创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考