tokio runtime/async code together with eframe/egui possible?

[gh0st42]

It's really amazing how easy and fun it is to write GUI stuff with egui!
As I'm currently working with a lot of different gRPC services, I am making heavy use of the tonic. This crate uses tokio and async/await.
It would be super nice to put an egui frontend on top of some of our code.

Is it even possible to use egui and eframe with async code in a more or less elegant way? eframe::run_native does work in #[tokio::main] but how can I update UI stuff in the most idiomatic way from tokio::spawned async functions.

I only found the HTTP fetching stuff in the egui_web code but no examples using tokio runtime on the desktop.

[parasyte]

It's possible, you just have to run the async runtime off the main thread (because most operating systems want the main thread to handle UI events, and the event loop blocks). You can spawn the tokio executor in a thread instead of trying to transform the main function into an async function with the #[tokio::main] proc macro.

Updating the UI is just a matter of communicating between the two threads using channels. There shouldn't be any surprises here.

[parasyte]

If you are going to await just a single future, you might want to consider using pollster in a thread.

For recurrent async tasks, you would build the runtime in the main thread and hold an EnterGuard on the stack so that you can call tokio::spawn() from your UI. Move the runtime into its own thread that blocks on a future. The future doesn't have to do anything at all; it can be an endless loop that calls tokio::time::sleep() if you want. Or it can be a message processor like an actor system. Or it can simply await an "exit signal" and return.

The core takeaway is that the runtime should run in its own thread and it will handle any async tasks that are spawned from any other thread, including the GUI thread. When you need to await the async task, don't block the GUI thread. Instead you can spawn a new thread and block on the task within it.

Communicate back to the GUI thread with something like winit's Event::UserEvent<T>. If you don't have access to winit, you can use an mpsc channel and poll the receiver with try_recv() in the GUI render loop. You might need a timer or some other event to pump the event loop if you do it this way. Seeing updates "only when moving the mouse" is a tell-tale indication.

[parasyte]

Since @Qark-dev asked for a practical example and it may not be entirely clear from the prose how the dots are connected, here you go: https://github.com/parasyte/egui-tokio-example

[ChrisRega]

I also wrote together an example of async-wrapping members for either generic single values or lists of values: https://github.com/ChrisRega/example-blog-client. Check the members of the application state class and how they are composited by the blog api from rather generic primitives. I still don't like that I have to work with a trait-object to get rid of the complex updating signature, but at least it covers something, has error handling and works.

[SacrilegeWasTaken]

Greetings, experienced developers. I would like to know how you using the same data (with like tokio::sync::Mutex or tokio::sync::RwLock) in async & sync threads. Using blocking_lock() in sync with lock().await in async causing deadlocks also as rt.block_on(async {...lock().await }) in sync with lock().await in async. I have no idea how to do that. Sorry for dumb questions, I'm newbie in rust and in programming at all.

[alexforencich]

Greetings, experienced developers. I would like to know how you using the same data (with like tokio::sync::Mutex or tokio::sync::RwLock) in async & sync threads. Using blocking_lock() in sync with lock().await in async causing deadlocks also as rt.block_on(async {...lock().await }) in sync with lock().await in async. I have no idea how to do that. Sorry for dumb questions, I'm newbie in rust and in programming at all.

The recommendation I have seen is simply to avoid using the tokio sync primitives entirely. There are some trade-offs with this approach (like you can't hold a lock across an await), but so far it has been working well for my application. There are also approaches like arcswap and arcshift that avoid locking entirely. But, it's also generally advisable to figure out how to properly separate the back end and front so that the front end isn't directly interacting with anything async, generally this will involve some sort of message-passing scheme through channels/queues (e.g. tokio mpsc). When done properly, you shouldn't have much code that interacts with both sync and async.

[ar37-rs]

@gh0st42 surely possible, here it's: https://github.com/ar37-rs/eframe_tokio_app