Rust中将加密和压缩操作适配为异步的目的是什么？

Question

在我的理解中，异步只能处理读写sockets或文件等I/O密集型任务，而不能处理加密、压缩等CPU密集型任务。

所以在 Rust Tokio Runtime 中，我认为只需要使用spawn_blocking来处理 CPU 密集型任务。 但我看过这个 repo ，例子是

#[tokio_02::main]
async fn main() -> Result<()> {
    let data = b"example";
    let compressed_data = compress(data).await?;
    let de_compressed_data = decompress(&compressed_data).await?;
    assert_eq!(de_compressed_data, data);
    println!("{:?}", String::from_utf8(de_compressed_data).unwrap());
    Ok(())
}

这个库在压缩和异步 I/O 类型之间创建了适配器。

我有3个问题：

1. 等待压缩/解压缩的目的是什么？

2. 这些适配器是必要的还是我对异步的理解错误？

3. 我可以直接在 Tokio 多线程运行时中进行压缩操作吗？ 像这样

async fn foo() {
    let mut buf = ...;
    compress_sync(&mut buf);
    async_tcp_stream.write(buf).await;
}

Answer 1

在我的理解中，异步只能处理读写sockets或文件等I/O密集型任务，而不能处理加密、压缩等CPU密集型任务。

这是误导。 异步构造旨在与非阻塞操作一起使用，而不管下面涉及哪种资源。 例如，将计算委托给单独线程的未来将是async / await的有效使用。

话虽如此，异步压缩之所以有用，是因为它们暴露了也适用于异步编程的I/O 适配器。 尽管这些压缩算法主要受 CPU 限制，但它们可以从任意读取器或写入器提供的批量工作，这意味着进程可能必须等待 I/O 执行。

例如参见bufread::ZstdDecoder的文档

该结构实现了AsyncRead接口，将从底层 stream 读取压缩数据，并发出未压缩数据的 stream。

这是您使用诸如flate2::bufread::GzDecoder类的同步字节源适配器所没有的。 即使您只使用compress function，它的同步版本也会在等待读取或写入数据的可能性时阻塞。

也可以看看：

• Rust 中异步/等待的目的是什么？
• 在异步代码中使用同步文件 IO 库