Fix: Do not use tokio in SourceEntry::verify_hash()

Because tokio seems to block forever here when "read()"ing the file to
memory, we use the `std::fs` API here.

This blocks, but is called async in tokio anyways, so we at least get
_some_ parallelization.

It is at least "a bit" parallelized, as this only allows parallelization
up to N `read()`s, where N is the number of tokio runtime threads, which
is the number of cores of the machine this is called on.

The `tokio::fs` API is a wrapper around `std::fs` anyways, right now.
So until tokio can work with async OS API calls (io_uring anyone?),
this is not worse as `tokio::fs`.

Signed-off-by: Christoph Prokop <christoph.prokop@atos.net>
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
Tested-by: Christoph Prokop <christoph.prokop@atos.net>
Tested-by: Matthias Beyer <matthias.beyer@atos.net>

1 files changed, 4 insertions, 6 deletions

diff --git a/src/source/mod.rs b/src/source/mod.rs
index 81bf34d..c2a5bb0 100644
--- a/src/source/mod.rs
+++ b/src/source/mod.rs
@@ -81,20 +81,18 @@ impl SourceEntry {
     }
 
     pub async fn verify_hash(&self) -> Result<()> {
-        use tokio::io::AsyncReadExt;
+        use std::io::Read;
 
         let p = self.source_file_path();
 
         trace!("Reading to buffer: {}", p.display());
         let mut buf = vec![];
-        tokio::fs::OpenOptions::new()
+        std::fs::OpenOptions::new()
             .create(false)
             .create_new(false)
             .read(true)
-            .open(&p)
-            .await?
-            .read_to_end(&mut buf)
-            .await?;
+            .open(&p)?
+            .read_to_end(&mut buf)?;
 
         trace!("Reading to buffer finished: {}", p.display());
         self.package_source