Переполнение стека tokio-runtime-worker в функции хеширования

Я пишу небольшое приложение для удаления дубликатов файлов (и для отработки навыков работы с Rust, с которым я относительно новичок!).

В рамках обучения (и поскольку у меня есть опыт управления мультимедиа с использованием очень больших файлов) я полон решимости обеспечить эффективную работу всех ядер моей машины. С этой целью я использую крейт времени выполнения Tokio и deadqueue в качестве реализации очереди.

Итак, код моего рабочего потока выглядит следующим образом (worker_count в настоящее время инициализируется количеством ядер, заданным num_cores, которое можно будет настроить из параметров командной строки):

    println!("Starting up {} worker threads...", worker_count);
    for n in 0..worker_count {
        let rxq = queue.clone();
        tokio::spawn(async move {
            eprintln!("INFO Thread {}", n);
            let _ = io::stderr().flush();
            loop {
                let ff = rxq.pop().await;
                eprintln!("Popped {}", ff.fullpath().display());
                
                process_item(ff).await;
            }
        });
    }

и функцияprocess_item определяется следующим образом:

async fn process_item(mut item:FoundFile) -> () {
    match item.calculate_sha().await {
        Ok(_)=>{}
        Err(e)=>{
            println!("ERROR Could not checksum: {}", e)
        }
    }
    ()
}

(с помощью spawn_blocking создан отдельный поток, который выполняет асинхронное сканирование и помещает FoundFile объекты в очередь)

calculate_sha() определяется в блоке impl FoundFile:

    pub async fn calculate_sha(&mut self) -> Result<String, Box<dyn Error> > {
        let mut file = tokio::fs::File::open(self.fullpath()).await?;
        let mut hasher = Box::new(Sha256::new());

        //let mut buffer: [u8; BUFFER_SIZE] = [0; BUFFER_SIZE];
        let mut buffer = vec![0_u8; BUFFER_SIZE];

        eprintln!("SHA calculation on {}", self.fullpath().display());


        while file.read(&mut buffer).await? > 0 {
            hasher.update(&buffer);
        }

        let final_result = encode(hasher.finalize());
        self.sha = Some(final_result.clone());
        Ok( final_result )
    }

по сути это то же самое, что я бы сделал в C, C++, Scala и т. д. — откройте файл, создайте хеш, настройте локальный буфер для 1 чанка, затем повторно заполните буфер из файла и вставьте в хеш ( обновление состояния хеширования) до тех пор, пока в файле не закончатся данные. Таким образом, мои требования к памяти должны быть ограничены одним куском и накладными расходами на состояние хеширования. RAII должен позаботиться о том, чтобы все было очищено. (Функция encode — это hex::encode, кстати, здесь это не актуально!)

Компилятор принимает все это нормально, но когда я на самом деле пытаюсь его запустить, я получаю довольно бесполезную информацию:

Starting up 8 worker threads...

thread 'tokio-runtime-worker' has overflowed its stack
fatal runtime error: stack overflow

Комментирование блока file.read() / hasher.update() означает, что он работает нормально (хотя, конечно, на самом деле ничего не происходит!).

Однако я не могу понять, что может быть причиной переполнения. Я ничего не повторяю, просто неоднократно вызываю hasher.update с локальным буфером. Как вы можете видеть из приведенного выше кода, я попытался убедиться, что оба hasher и buffer находятся в куче, используя Box и Vec соответственно, и убедился, что buffer инициализирован, но ничего, кроме комментирования цикла, похоже, не имеет никакого значения. .

Самое странное, что когда я отслеживаю выполнение с помощью операторов eprintln! (предполагая, что вывод STDERR не буферизуется, как и в случае с другими языками, которые я использовал), я даже не вижу строку INFO Thread {n}.

Очевидно, что под капотом происходит что-то более тонкое, но я немного не понимаю, что это такое - может ли кто-нибудь, кто знает Токио лучше, чем я, пролить свет на это?

Большое спасибо!