环保异步

为异步IO工作提供符合人体工程学的实用工具，易于在本地和浏览器上交叉编译。

• 使用 [enfync::builtin::Handle::spawn()] 来启动与平台无关的IO任务。返回的 enfync::PendingResult<R> 可以用作任务上的join处理。在您的异步工作中遇到的任何任务错误将被丢弃，并用 [enfync::ResultError::TaskFailure`]. 替换。

此crate旨在为希望在不牺牲本地构建性能的情况下，以符合人体工程学的方式支持WASM目标的项目。为了实现这一目标，API被限制在本地/浏览器异步能力之间的最大公约数。特别是，没有内置的任务中止机制，并且 enfync::blocking 实用工具仅限于非WASM构建。

特性

• default: builtin
• builtin: 启用 enfync::builtin 模块。句柄 enfync::builtin::Handle 是 enfync::Handle 特征的平台特定实现（在非WASM上为 tokio，在WASM上为 wasm-bindgen-futures）的别名。

重要说明

• 在WASM中，一次只能运行一个任务。第一个“任务”总是fn main()，之后是fn main()期间产生的任何任务。任何长时间运行的任务，包括fn main()，都会阻塞所有其他任务。这意味着除非你从头开始开发你的项目时考虑WASM，否则你基本上无法从这个crate中受益。
• 我们不提供任何处理“Web Workers”的API，Web Workers是一种类似于线程的浏览器功能，但它们在启动和交互方面有巨大的开销。

用法

使用内置的spawner安排异步工作。如果检测到现有的异步运行时，我们将采用它，否则将回退到内置的默认运行时。

let pending_result = enfync::builtin::Handle::adopt_or_default().spawn(
    async move {
        // your async work
    }
);

使用PendingResult等待结果，它是在任务上的join handle。

let result = pending_result.extract().await.unwrap();

推荐的WASM构建

我们提供了一个自定义的release-wasm配置文件，该文件启用panic = "abort"并针对小型二进制文件进行优化。还有一个相应的dev-wasm配置文件，也启用panic = "abort"。目前wasm-pack 不支持自定义配置文件，所以我们只能满足于一个更详细的构建脚本，该脚本会覆盖构建文件。

1. 准备工具

• rustuptarget install wasm32-unknown-unknown
• cargoinstall wasm-pack
• install wasm-opt

2. 构建（这会构建两次，因为我们想要wasm-pack的便利输出和release-wasm配置文件；根据需要可以省略wasm-pack部分）

wasm-pack build --target no-modules --mode no-install &&
cargo build --profile=release-wasm --target wasm32-unknown-unknown &&
wasm-bindgen --out-dir ./pkg --target no-modules ./target/wasm32-unknown-unknown/release-wasm/enfync.wasm

3. 优化WASM二进制文件

• wasm-opt-Os pkg/enfync_bg.wasm-o pkg/enfync_bg.wasm
• 有关进一步优化的信息，请参阅rustwasm参考。

4. 压缩WASM二进制文件

• TODO: gzip

运行WASM

• 测试：wasm-pack test --firefox --headless。请注意，由于wasmtimer依赖项引起的模糊错误，目前--node测试失败。
• 在本地运行你的程序：wasm-server-runner工具

选项

• TOKIO_WORKER_THREADS（环境变量）：默认IO任务池的大小（仅限本地构建）。

性能说明

• 为[enfync::builtin::native::TokioHandle::default()]的默认线程池初始化被推迟到你第一次创建默认handle时。

与 prokio 的比较

优点

• 可以像连接句柄一样等待 [enfync::PendingResult<R>::extract()]。
• [enfync::builtin::native::TokioHandle::try_adopt()] 可以采用现有的常规 tokio 运行时（无需依赖 prokio 的 LocalSet 特定设计）。
• enfync::ResultReceiver/enfync::Handle 抽象允许用户轻松实现自己的自定义运行时（您甚至可以实现一个基于 prokio 的 Handle）。

缺点

• prokio 更为成熟，具有运行时构建器、固定的任务同步原语等。
• prokio 兼容 ?Send 任务，而 enfync 只允许 Send 任务。这意味着对于需要在不同任务间传递 WebAssembly 类型的项目来说，prokio 比较优于 enfync。