Any documentation about the main thread?

[moxaj]

The question is kind of vague, let me explain: I had a tauri command, non-async, which hid the caller window. Doing so completely froze another visible window, and I just spent like 2 hours trying to figure out why :( (making the command async solved the issue). I would have expected that anything to do with window management HAD to be done on the main thread, but apparently this is not the case. I have found this issue, but this provides no further explanation. Nor is it mentioned in the official docs (the provided examples are async though..). Should one just make all commands async? What is the purpose of the main thread?

[FabianLars]

What is the purpose of the main thread?

Some stuff must run on main thread, some stuff must run on a non-main thread. Also, the main thread should be slightly faster (no context switching or whatever).
The main thing to have in mind is that doing something blocking in commands which run on the main thread will also block the UI (which also runs on the main thread). So i guess you could say async commands (or sync command annotated with #[command(async)]) are generally the safer bet 🤷

That said the frozen window sounds like a bug. So if you can i'd appreciate if you can create an issue for it with a minimal reproduction repo 🙏

window management HAD to be done on the main thread

Actually it used to be the other way around, window manipulation was only allowed on non-main threads. Nowadays it should be only window.close() that needs to be run on a seperate thread.

[moxaj]

In my case the command was essentially

#[tauri::command]
fn hide_overlay_window(overlay_window: tauri::Window) {
    overlay_window.hide().unwrap();
    // ...
}

I think I could have hidden the window from the frontend, but decided against it for some reasons. Also, I think my issue is the same as #2311, which wasn't considered a bug.

[FabianLars]

Yeah, but back then window manipulation wasn't allowed on the main thread, this changed 2 months later via #2659.

So it's either a bug with hide() or you did some blocking stuff in // ...

That said i double checked it in my project and window.hide() alone does not freeze the second window (tested on Windows). So it looks like it indeed comes down to what other stuff you do in that function (or main-thread commands in general).

[moxaj]

Sorry, I don't really have the time (short term) to work on a minimal repro, but the ... part accesses and mutates some state managed by the app:

*app.state::<Mutex<State>>().lock().unwrap() = state

[JonasKruckenberg]

Inspect your code for mutex deadlocks, i.e. calling lock() twice. A deadlock would explain the frozen window, since you would have basically locked up the main thread.

[moxaj]

@JonasKruckenberg Thanks for the suggestion! Here are the changes I made:

#[tauri::command]
fn hide_overlay_window(app: tauri::AppHandle, overlay_window: tauri::Window) {
    overlay_window.hide().unwrap();
    match app.state::<Mutex<State>>().try_lock() {
        Ok(mut state) => {
            println!("No mutex error!");
            *state = State::Hidden;
        },
        Err(error) => println!("Mutex error {:?}", error),
    }
}

If I use #[tauri::command(async)], and call this from the overlay window while having the other window open, it works as expected (prints No mutex error!). However, if I remove the async, it does not print anything, which would indicate that overlay_window.hide().unwrap(); blocks, right?