How do you gracefully shutdown tauri event loop without exiting the process?

[cutephoton]

The use case: I am using tauri to bolt on a user interface to configure a service (via the system tray). (Clicking the system tray shows the window, and closing it hides, rather than closes, the window.) Tauri is running on its own thread. The service controls the life cycle and, given the design, the UI resources need to be cleaned up at a point prior to terminating the process. Stated differently, the service needs to signal the thread which is running tauri event loop clean up resources, to exit the thread handling the event loop, but not exit the process.

This seems feasible from reviewing the source code, buuuut... I'm stuck on how to accomplish it given my relative lack of experience with rust.

AppHandle provides an exit, but this terminates the process...

  pub fn exit(&self, exit_code: i32) {
    self.cleanup_before_exit();
    std::process::exit(exit_code);
  }

I know there is run_iteration, but I'm not sure how to signal the event loop from another thread so that I can stop iterating? Can somebody give me a hint? I've been going in circles for 8 hours!

(As an engineer, tbh, I have a beef about the appropriateness of a library calling std::process::exit. And that note, I'm going to take some deep breaths, try to forgive this function, and go on vacation.)

Thanks!

[FabianLars]

you'll probably figured it out by now but i'll add something anyway

I know there is run_iteration, but I'm not sure how to signal the event loop from another thread so that I can stop iterating? Can somebody give me a hint?

Probably via rust's mpsc::channel and the Receiver's try_recv method.

Also about app.exit using process::exit - this is exactly what it's supposed to do. It's supposed to be a wrapper for process::exit with tauri-specific clean-up. It's not a shutdown-the-eventloop kinda thing.
What would be nice tho if we would expose the cleanup function so that devs can call that on demand themselves 👍

[cutephoton]

Agree that would be nice.

run_iterator is blocking, right? To use try_recv, one would need an event to trigger run_iterator to return?

I did figure out a workaround. I ended up using a global event and listening for that in combination with run_iteration. It proved to be a tricky problem to solve because another library I was working with did exactly the same thing and assumed no other resources needed to be cleaned up.