PDFRip currently performs it's tasks with traditional threads causing certain logic to become more cumbersome compared to how I think it could be implemented in an async environment.
This is supported by how engine.rs has seen bugs such as #14 suggesting it's a tad too complicated.
I propose reimplementing PDFRip to be async instead by utilizing the Tokio ecosystem.
The benefits are:
We have access to Tokio's async runtime, potentially improving performance.
We have access to tokio-util's CancellationTokens and TaskTrackers as well as Tokio's Select! macro and ctrl-c signal handling.
This Could be useful when implementing #17.
We can remove our dependency on Crossbeam and utilize the channels in Tokio.
The current problems that I think need to be resolved are
We will probably need to make the Producer traits Async, which is supported in rust since 1.75. This is to allow cancelling production of passwords when implementing #17 .
We must lock our minimum rust version to 1.75 if we use async traits.
Finally many web frameworks in rust use async functions, which means if we implement a REST api as suggested by me in #18 would require us to do this anyways.
PDFRip currently performs it's tasks with traditional threads causing certain logic to become more cumbersome compared to how I think it could be implemented in an async environment. This is supported by how engine.rs has seen bugs such as #14 suggesting it's a tad too complicated.
I propose reimplementing PDFRip to be async instead by utilizing the Tokio ecosystem.
The benefits are:
The current problems that I think need to be resolved are