Время жизни Rust, данные перетекают в другие ссылки

Я написал следующий код, который фильтрует поток данных, который работал нормально, пока я не перешел с анализа простых чисел на типы, привязанные к временам жизни, такие как &str и &[u8].

use wirefilter::{ExecutionContext, Filter, Scheme};

lazy_static::lazy_static! {
    static ref SCHEME: Scheme = Scheme! {
        port: Int,
        name: Bytes,
    };
}

#[derive(Debug)]
struct MyStruct {
    port: i32,
    name: String,
}

impl MyStruct {
    fn scheme() -> &'static Scheme {
        &SCHEME
    }

    fn filter_matches<'s>(&self, filter: &Filter<'s>) -> bool {
        let mut ctx = ExecutionContext::new(Self::scheme());
        ctx.set_field_value("port", self.port).unwrap();
        ctx.set_field_value("name", self.name.as_str()).unwrap();

        filter.execute(&ctx).unwrap()
    }
}

fn main() -> Result<(), failure::Error> {
    let data = expensive_data_iterator();
    let scheme = MyStruct::scheme();
    let filter = scheme
        .parse("port in {2 5} && name matches \"http.*\"")?
        .compile();

    for my_struct in data
        .filter(|my_struct| my_struct.filter_matches(&filter))
        .take(2)
    {
        println!("{:?}", my_struct);
    }

    Ok(())
}

fn expensive_data_iterator() -> impl Iterator<Item = MyStruct> {
    (0..).map(|port| MyStruct {
        port,
        name: format!("http {}", port % 2),
    })
}

Если я попытаюсь скомпилировать его, компилятор выйдет из строя:

error[E0623]: lifetime mismatch
  --> src/main.rs:26:16
   |
21 |     fn filter_matches<'s>(&self, filter: &Filter<'s>) -> bool {
   |                           -----           ----------
   |                           |
   |                           these two types are declared with different lifetimes...
...
26 |         filter.execute(&ctx).unwrap()
   |                ^^^^^^^ ...but data from `self` flows into `filter` here

error: aborting due to previous error

error: Could not compile `wirefilter_playground`.

To learn more, run the command again with --verbose.

Process finished with exit code 101

моя первая мысль заключалась в том, что у себя и фильтра должно быть одинаковое время жизни в fn filter_matches<'s>(&self, filter: &Filter<'s>) -> bool, но если я изменю подпись на fn filter_matches<'s>(&'s self, filter: &Filter<'s>) -> bool, я начну получать эту ошибку:

error: borrowed data cannot be stored outside of its closure
  --> src/main.rs:38:29
   |
33 |     let filter = scheme
   |         ------ ...so that variable is valid at time of its declaration
...
38 |         .filter(|my_struct| my_struct.filter_matches(&filter))
   |                 ----------- ^^^^^^^^^ -------------- cannot infer an appropriate lifetime...
   |                 |           |
   |                 |           cannot be stored outside of its closure
   |                 borrowed data cannot outlive this closure

error: aborting due to previous error

error: Could not compile `wirefilter_playground`.

To learn more, run the command again with --verbose.

Process finished with exit code 101

Я не понимаю причину, Filter<'s> привязан к SCHEME, который генерируется лениво и привязан к 'static, что имеет смысл не позволять filter.execute ссылаться на &self.name.as_str(), потому что он будет изжит, но это не filter.execute(&ctx), подпись которого pub fn execute(&self, ctx: &ExecutionContext<'s>) -> Result<bool, SchemeMismatchError> предполагается, что ссылки будут отброшены, как только он закончится, потому что у него нет других жизней?

Чтобы попробовать скомпилировать приведенный выше код, вы можете использовать Cargo.toml:

[package]
name = "wirefilter_playground"
version = "0.1.0"
edition = "2018"

[dependencies]
wirefilter-engine = "0.6.1"
failure = "0.1.5"
lazy_static = "1.3.0"

PS: Это можно решить, скомпилировав метод as inside filter_matches, но это было бы плохо, потому что пользователь получал бы ошибку синтаксического анализа только при попытке фильтрации, и потенциально это могло быть медленнее.


rust rust-crates
person Jayson Reis    schedule 03.05.2019    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я вижу 2 способа решить эту проблему:
1) продлить время жизни self.name. Этого можно добиться, собрав expensive_data_iterator, скажем, в Vec.

--- let data = expensive_data_iterator();
+++ let data: Vec<_> = expensive_data_iterator().collect();

2) уменьшить срок службы filter.

--- let filter = scheme.parse("...")?.compile();
+++ let filter = scheme.parse("...")?;

--- .filter(|my_struct| my_struct.filter_matches(&filter))
+++ .filter(|my_struct| my_struct.filter_matches(&filter.clone().compile()))

Я пропустил некоторые другие мелкие изменения. И да, filter_matches<'s>(&'s self, ...) обязательно в любом случае.

PS да, 2-й вариант работает, потому что my_struct переживает filter. Что ж, если оба подхода несколько плохи, то можно их комбинировать! Обработайте data кусками, собирая каждый в вектор.

const N: usize = 10; // or any other size
loop {
    let cur_chunk: Vec<_> = data.by_ref().take(N).collect();
    if cur_chunk.is_empty() {
        break;
    }
    let cur_filter = filter.clone().compile();
    // etc
}

он использует только O (N) памяти и компилирует фильтр в N раз меньше

person Laney    schedule 03.05.2019
comment
Спасибо за предложение! Первый я не могу использовать, потому что этот итератор может быть огромным и / или бесконечным. Второго я пытался избежать, потому что думал, что метод компиляции будет медленным процессом, не так ли? Кроме того, второй вариант работает, потому что клонированный FilterAst<'s> и его Filter<'s> существуют только в этой небольшой области? - person Jayson Reis; 03.05.2019
comment
@JaysonReis Да, насчет фильтра ты прав. Проверить мою правку - person Laney; 03.05.2019