Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

derive(Serialize) state: Fsm vs AsyncSeek #99

Open
dishmaker opened this issue Feb 11, 2025 · 1 comment
Open

derive(Serialize) state: Fsm vs AsyncSeek #99

dishmaker opened this issue Feb 11, 2025 · 1 comment

Comments

@dishmaker
Copy link

dishmaker commented Feb 11, 2025

Any async io function over trait AsyncSeek can be turned into a sans-io FSM.

I think that's a fact - just calling future.poll(..) on a clever object that pauses on seek and read calls is enough to simulate an ArchiveFsm.
So for example async_zip::ZipFileReader can be made into a sync sans-io interface with a wrapper.

Therefore, my open questions are:

  • Which paradigm is easier to write in Rust? sans-io or async?1
  • Which paradigm is faster to execute? sans-io or async?
  • Can we clone the EntryFsm state to remember decompressor state in the middle of 100 GB file with sans-io? 2
  • Can we serialize/save the EntryFsm state into JSON and resume it later with sans-io?3

Some answers are already in video fasterthanlime: The case for sans-io

Footnotes

  1. async fn is actually an FSM https://users.rust-lang.org/t/serde-async-state-machine/99648

  2. DecompressorOxide implements Clone

  3. async_zip ZipFileReader implements Clone, but not Serialize

@dishmaker
Copy link
Author

Well, sans-io rc-zip definitely wins.

async_zip::ZipEntryReader does not implement Clone.

@dishmaker dishmaker changed the title Theoretical question: Fsm vs AsyncSeek derive(Serialize) state: Fsm vs AsyncSeek Feb 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant