Emscripten 4.0.0 中 Module.postRun 回调执行机制的变化分析

在 Emscripten 4.0.0 版本中，开发者发现了一个与模块初始化流程相关的重要变化：Module.postRun 回调的执行时机发生了改变。这个变化影响了那些依赖特定初始化顺序的应用程序，特别是那些需要在模块完全初始化前后执行特定逻辑的场景。

问题背景

在 Emscripten 3.x 版本中，Module.postRun 回调会在模块初始化过程的特定阶段被自动调用。开发者通常利用这个机制来执行一些需要在模块完全初始化后运行的代码。然而，在升级到 4.0.0 版本后，许多开发者发现他们的 postRun 回调不再被调用，或者调用时机发生了改变。

技术原因分析

这一变化源于 Emscripten 4.0.0 对异步/等待(async/await)机制的全面采用。在之前的版本中，模块的初始化过程存在同步和异步两种路径，且两者的行为存在差异。4.0.0 版本通过使用 async/await 统一了这两种路径的行为，使得模块初始化过程更加一致。

具体来说，在 4.0.0 中：

1. 模块工厂函数现在可以内部使用 await 来等待 createWasm 函数的完成
2. run() 函数现在会实际执行初始化代码，而不是像之前那样可能被延迟
3. --post-js 代码现在总是在 run() 函数之后执行

影响范围

这一变化主要影响以下场景：

1. 在 --post-js 文件中添加 Module.postRun 回调的代码
2. 依赖 Module.postRun 回调在特定时机执行的初始化逻辑
3. 同时使用 --post-js 和 --extern-post-js 的复杂初始化流程

解决方案

对于受影响的代码，开发者可以考虑以下几种解决方案：

方案一：直接执行初始化代码

如果代码运行在模块已经初始化的上下文中，可以直接执行初始化逻辑，而不再通过 postRun：

if (runtimeInitialized) {
    callFoo();
} else {
    Module.postRun.push(callFoo);
}

方案二：在替代的初始化函数中处理

对于需要替换 EXPORT_NAME 函数的场景，可以在替代函数中处理初始化逻辑：

globalThis.sqlite3InitModule = function ff(...args){
    return originalInit(...args).then((EmscriptenModule)=>{
        // 手动执行 postRun 中未执行的代码
        if(EmscriptenModule.postRun && EmscriptenModule.postRun.length){
            EmscriptenModule.postRun.shift()(EmscriptenModule);
        }
        // 其他初始化逻辑
    });
};

方案三：迁移到 --pre-js

如果可能，将初始化代码迁移到 --pre-js 文件中，这样可以确保在模块构造前就设置好 postRun 回调。

最佳实践建议

1. 避免在 runtimeInitialized 为 true 后继续向 Module.postRun 添加回调
2. 考虑使用更明确的初始化标志来控制代码执行流程
3. 对于复杂的初始化场景，建立自己的初始化状态管理系统
4. 在升级到 4.0.0 时，仔细测试所有依赖初始化顺序的代码

未来发展方向

Emscripten 团队可能会在未来的版本中：

1. 对在运行时初始化后添加 postRun 回调的行为发出警告或错误
2. 提供更明确的模块生命周期事件系统
3. 改进文档，更清晰地说明各个初始化阶段的执行顺序

结论

Emscripten 4.0.0 对初始化流程的改进虽然带来了一些兼容性问题，但从长远来看，这种更加一致的行为对项目的可维护性和可预测性是有益的。开发者需要理解这些变化，并相应地调整他们的初始化代码结构。通过采用本文建议的解决方案，可以平滑过渡到新版本，同时建立更加健壮的初始化流程。