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.

[yorqat]

@parasyte any practical examples?

[jackyzsn]

I did something. Here is the code.

egui::Grid::new("config_grid")
        .num_columns(1)
        .spacing([40.0, 4.0])
        .show(ui, |ui| {
            ui.with_layout(egui::Layout::bottom_up(egui::Align::Center), |ui| {
                if ui.button("📎 Connect").clicked() {
                    let mut in_progress_c1 = in_progress.lock().unwrap();
                    *in_progress_c1 = true;

                    let mut status_c1 = status.lock().unwrap();
                    status_c1.clear();
                    status_c1.push_str("Connecting..");

                    let in_progress_c2 = Arc::clone(&in_progress);
                    let search_result_c1 = Arc::clone(&search_result);
                    let status_c2 = Arc::clone(&status);
                    thread::spawn(move || {
                        let search_result = &mut *search_result_c1.lock().unwrap();

                        let weather = retrieve_city_weather();
                        search_result.clear();
                        search_result.push_str(weather.unwrap().as_str());

                        let mut in_progress = in_progress_c2.lock().unwrap();
                        *in_progress = false;

                        let mut status = status_c2.lock().unwrap();
                        status.clear();
                        status.push_str("Ready");
                    });
                }
            });
        });

...

pub fn retrieve_city_weather() -> Result<String, Box<dyn Error>> {
    let url = "https://api.openweathermap.org/data/2.5/onecall?lat=43.7360196&lon=-79.492821&exclude=hourly,minutely&appid=8793424064af88ecfa3af87c2352b444&units=metric";

    let result = tokio::runtime::Builder::new_multi_thread()
        .enable_all()
        .build()
        .unwrap()
        .block_on(async {
            let mut headers = header::HeaderMap::new();
            headers.insert(
                header::CONTENT_TYPE,
                header::HeaderValue::from_static("application/json"),
            );

            let client = reqwest::Client::builder()
                .default_headers(headers)
                .build()
                .unwrap();
            let response = client.get(url).send().await.unwrap().text().await.unwrap();

            Ok(response)
        });

    result
}

[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.

[ar37-rs]

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