Function on_main_thread 

pub(crate) fn on_main_thread<R, T, F>(
    app: &AppHandle<R>,
    what: &'static str,
    read: F,
) -> Option<T>
where
    R: Runtime,
    T: Send + 'static,
    F: FnOnce(&AppHandle<R>) -> T + Send + 'static,

Run read on the windowing system’s main thread and hand back its result.

For the tauri getters that reach straight into the event loop’s window_target — available_monitors, primary_monitor, monitor_from_point, display_handle — which are not dispatched through the event loop and therefore must not be called from a tokio worker (#333). cursor_position and every window setter already dispatch and need no hop.

Deliberately not used for window creation: tauri-runtime-wry documents that create_webview “must be called from a separate thread, otherwise the channel will introduce a deadlock”, so the overlay builder has to stay on the caller’s thread.

read must return plain data, never a live handle, so the value is safe to use after the hop. The T: Send bound cannot enforce that — a live WebviewWindow would satisfy it — so it stays a convention callers have to honour.

Safe to call from the main thread as well as off it, which matters because both happen: tauri-runtime-wry’s send_user_message compares the calling thread to the event loop’s and runs the task inline when they match, rather than queueing it, so the value is already in the channel before recv_timeout is reached. No self-deadlock.

Returns None if the main thread is unreachable or too slow, which lets callers degrade rather than risk a hang. what names the read in that warning, because the consequences differ sharply between call sites.