对tokio :: spawn(异步移动中的变量生存期感到困惑 [英] Confused about variable lifetime in tokio::spawn(async move

问题描述

我对rust和tokio异步是陌生的，我正在尝试编译以下看似简单的代码:

I am new to rust and tokio async, and I am trying to compile the following seemingly straightforward code:

async fn network_handler(network_config: &config::NetworkConfig) -> Result<(), Error> {
    Ok(())
}

pub async fn run(network_config: &config::NetworkConfig) -> Result<(), Error> {
    let network_config_copy = network_config.clone();
    tokio::spawn(async move {
        network_handler(&network_config_copy).await
    }).await?
}

但是编译器抱怨:

error: cannot infer an appropriate lifetime
  --> src/network.rs:43:18
   |
43 | pub async fn run(network_config: &config::NetworkConfig) -> Result<(), Error> {
   |                  ^^^^^^^^^^^^^^ ...but this borrow...
44 |     let network_config_copy = network_config.clone();
45 |     tokio::spawn(async move {
   |     ------------ this return type evaluates to the `'static` lifetime...
   |
note: ...can't outlive the lifetime `'_` as defined on the function body at 43:34
  --> src/network.rs:43:34
   |
43 | pub async fn run(network_config: &config::NetworkConfig) -> Result<(), Error> {
   |                                  ^
help: you can add a constraint to the return type to make it last less than `'static` and match the lifetime `'_` as defined on the function body at 43:34
   |
45 |     tokio::spawn + '_(async move {
   |     ^^^^^^^^^^^^^^^^^

从之前在该主题上的讨论和示例中，我了解到将对network_config的引用传递给生成的闭包会导致生命周期问题，因为单独的线程可能会超出network_config.这就是为什么我将network_config的副本移至生成的线程，但是似乎仍然存在生命周期歧义的原因.

From the previous discussions and examples I have found on the subject, I understand that passing a reference to network_config to the spawn-ed closure would cause lifetime problems since the separate thread may outlive network_config. This is why I am moving a clone of network_config to the spawned thread, but there still seems to be a lifetime ambiguity.

我是否可以给编译器一些额外的提示，以便它正确地获得生存期?还是我整个事情做错了?

Is there any extra hint I could give the compiler so that it correctly gets the lifetimes ? Or am I doing the whole thing wrong ?

注意:NetworkConfig类定义为:

Note: the NetworkConfig class is defined as:

#[derive(Debug, Deserialize)]
pub struct NetworkConfig {
    pub bind: String,
    pub node_key_file: String,
}

推荐答案

如果要克隆 NetworkConfig 值，请为其声明 Clone 特性:

If you want clone the NetworkConfig value declare for it the Clone trait:

#[derive(Debug, Clone)]
pub struct NetworkConfig {
    pub bind: String,
    pub node_key_file: String,
}

否则，对于接收方方法查找的规则，您最终将通过以下方式在引用上调用 Clone 以下 克隆实现者:

Otherwise, for the rules of receiver method lookup you will end up with invoking a Clone on a reference through the following Clone implementer:

impl<'_, T> Clone for &'_ T

克隆的引用的生命周期将绑定到 clone()调用的范围.

And the cloned reference will have a lifetime bound to scope of clone() invocation.

使用 derive(Clone)编译 run 函数，但是仅当 network_config 参数具有'static 生存期，因为 tokio :: spawn 生存期要求.

With derive(Clone) the run function compiles, but it works only when network_config argument has 'static lifetime, because of tokio::spawn lifetime requirement.

可能这不是您想要的.如果是这种情况，请按值传递 NetworkConfig 并将其最终克隆到调用方中语境.

Probably this is not what you want. If this is the case pass NetworkConfig by value and eventually clone it in the caller context.

use async_std::io::Error;
use tokio;

mod config {

    #[derive(Debug, Clone)]
    pub struct NetworkConfig {
        pub bind: String,
        pub node_key_file: String,
    }
}

async fn network_handler(network_config: &config::NetworkConfig) -> Result<(), Error> {
    println!("using {:?}", network_config);
    Ok(())
}

pub async fn run(network_config: config::NetworkConfig) -> Result<(), Error> {
    tokio::spawn(async move { network_handler(&network_config).await }).await?
}

#[tokio::main]
async fn main() {
    let config = config::NetworkConfig {
        bind: "my_bind".to_owned(),
        node_key_file: "abc".to_owned(),
    };

    tokio::spawn(run(config.clone()));
}

您可能会问为什么这行得通，实际上引用仍然传递给 network_handler().

You may ask why this works, indeed a reference is still passed to network_handler().

这是因为 network_config 已在生成异步块内移动，并且这样就可以为推断出的异步块类型获得静态生存期.

This is because network_config is moved inside the spawn async block and this makes gaining static lifetime for the inferred type of the async block.

这篇关于对tokio :: spawn(异步移动中的变量生存期感到困惑的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！