Async Executor

[tauri-apps]

Async Executor

[lucasfernog]

well we have that lib that allows tauri commands to be async, and Tensor had some ideas about moving it to core.

[lucasfernog]

Right now we use async operations here:
https://github.com/tauri-apps/tauri/blob/dev/tauri/src/lib.rs

tauri/tauri/src/app/runner.rs

Line 17 in ae51d95

thread::spawn(|| {

The main one we should update is the lib.rs because that's where every Rust API call goes.

[tensor-programming]

Id also recommend that you look again at event.rs. Got a thread_local! call in there. It may be worth implementing task_local! if we are going to go with Tokio.

[khionu]

As I mentioned, a custom executor would be a more sound decision for us, despite the work involved. An executor, generally speaking, is a way to centralize background work, so it makes sense that we'd want to keep that tailored to what we need. Tokio, while convenient for a lot of use cases, is a bit on the bloated side.

The event dispatcher is a prime candidate to be turned into a custom reactor. It would essentially get the Futures from the user code on each iteration and push them to the Futures reactor (which we would probably have 2-4 of, and could be a user configuration) to be handled as futures.

The update command could be done as a Future, but eventually that will need to be more complex for fancy update processes. Regardless of the complexity, we will be able to put that on a general purpose reactor.

This will definitely be a bigger-picture change, and I would like to encourage we think of this as a long-term project. Axiom's refactor took me over 150 hours of work (guesstimating), and it still needs adjustments.

[tensor-programming]

I did consider using Actix at one point for the entire platform but it would require a major rewrite. Just implementing futures and green threads in the event manager is a good idea and it is definitely worth looking into. It would make the library much more preformant and help with distributing the tasks.

This weekend Ill see if I can get a bit of it working with tokio and an executor. Insider of the event queue we are already using a mutex and an Arc; adding on an executor and a spawner might smooth out the workflow.

One thing that I am a bit cautions about is using the nightly branch. As it is right now, Tauri depends on the stable branch. If we can avoid using nightly then we should.

[khionu]

As discussed on Discord, we'll not be using Tokio.

[tensor-programming]

We could use something like fibers rather then writing an entire executor given how little async work we do in the project. Native threading is fine but green threads might be better for our event system.

[khionu]

An option: https://github.com/dwango/fibers-rs

[nothingismagick]

Nice @khionu. Would you consider looking at:

https://github.com/tauri-apps/tauri/blob/feature/iframe/tauri/src/event.rs

and making a proposal implementation with fibers and futures?

[himself65]

What's the current state of this issue?

[nothingismagick]

I'm not sure at the moment. We just moved to the new webview bindings, and Khionu has left the project. @lucasfernog - is this something we can address or should it be closed?

[lucasfernog]

I'm closing this issue since we started working on async support here: #1169
We're going to start with Tokio for simplicity but more async runtimes will be implemented in the future.