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

Migration to Tokio #419

Open
kamiyaa opened this issue Aug 30, 2023 · 7 comments
Open

Migration to Tokio #419

kamiyaa opened this issue Aug 30, 2023 · 7 comments
Labels
question Further information is requested

Comments

@kamiyaa
Copy link
Owner

kamiyaa commented Aug 30, 2023

Thinking of taking advantage of async/await and green threads to potentially make joshuto more lightweight.
Would love to hear some feedback on this.
Not entirely sure if it will help with performance, or just increase build times.

@kamiyaa kamiyaa added the question Further information is requested label Aug 30, 2023
@Beethoven-n
Copy link
Contributor

i think it might be worth fixing the arm build issues first, so chromebooks and macs can use joshuto. i'd do it after that point, if it were me

@kamiyaa
Copy link
Owner Author

kamiyaa commented Aug 30, 2023

i think it might be worth fixing the arm build issues first, so chromebooks and macs can use joshuto. i'd do it after that point, if it were me

What issues are you having on arm? I'm able to compile and run joshuto on m2 macbook

@Lzzzzzt
Copy link
Contributor

Lzzzzzt commented Sep 9, 2023

are there some ways to run benchmark between tokio version and current version

@kamiyaa
Copy link
Owner Author

kamiyaa commented Sep 13, 2023

are there some ways to run benchmark between tokio version and current version

Good question

@Beethoven-n
Copy link
Contributor

i think it might be worth fixing the arm build issues first, so chromebooks and macs can use joshuto. i'd do it after that point, if it were me

What issues are you having on arm? I'm able to compile and run joshuto on m2 macbook

joshuto still doesn't compile on termux with a mismatched types error at src/ui/widgets/tui_file_preview.rs:44:45

@fritzrehde
Copy link
Contributor

My take on using Tokio (I use Tokio/async Rust in my own TUI project called watchbind): You have to either go all in on Tokio/async Rust or not use it at all. This is because you are not really allowed to call synchronous code inside async functions, and most of your functions will become async, otherwise these synchronous calls will block the entire application and destroy the purpose of an async runtime (there are ways to mitigate this, but all I know of is basically performing sync function calls on a separate thread. Tokio has good docs on this).
For me, a huge advantage of async Rust is: I can wait for multiple async functions to complete at once with select!, and then do whatever I want when the first one completes. I know this might not be relevant for your application, but it helped me get rid of some ugly/inefficient uses of active polling.
Anyways, Tokio has nice support for async file IO. It also has equivalents for pretty much everything you would need/already use (e.g. mpsc channels etc.).
I'm personally very happy that I made the switch to Tokio and async Rust, I learned a lot about it, but it's also not super trivial. If you're not familiar with async Rust/Tokio yet, I can highly recommend Crust of Rust: async/await YouTube video by Jon Gjengset.
Switching to Tokio would probably be quite a big refactor, so you'd have to evaluate whether it's worth it. I know of (but haven't used) yazi, which is another TUI file manager in Rust that indeed uses async Rust. Maybe you can look at their code, or ask more specific questions there.

@fritzrehde
Copy link
Contributor

I just found this issue in yazi describing some of their usage of Tokio, might be useful to check out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants