fix(runtime-wry): query monitors on main thread from runtime handle#15630
fix(runtime-wry): query monitors on main thread from runtime handle#15630tenderdeve wants to merge 4 commits into
Conversation
WryHandle::primary_monitor, monitor_from_point and available_monitors read the event loop's window target directly on the calling thread. That window target is not thread safe, so calling these functions from a background thread races with the UI thread and can segfault or corrupt the heap. Route the three queries through the event loop like cursor_position already does, so the window target is only accessed on the main thread. Closes tauri-apps#15170
Reuse the existing event_loop_window_getter! macro (as cursor_position does) instead of hand-rolling the channel + send_user_message boilerplate in primary_monitor, monitor_from_point and available_monitors. These methods return bare Option/Vec, so a small closure absorbs the macro's internal `?`.
|
@FabianLars done in fc2078b — switched all three ( One wrinkle: the macro expands to Reads cleaner for |
|
Ah shit i didn't see the |
…tor queries" This reverts commit fc2078b.
If send_user_message errors the event loop will never reply, so recv() would block the calling thread forever. Return None / an empty Vec on a send error instead of waiting.
|
@FabianLars done in a989173 (revert in 57bd57c) — no worries on the back-and-forth. Back to the explicit |
Package Changes Through a989173There are 12 changes which include tauri with minor, tauri-build with minor, tauri-utils with minor, tauri-runtime-wry with minor, tauri-runtime with minor, tauri-codegen with minor, tauri-macros with minor, tauri-plugin with minor, tauri-cli with minor, tauri-macos-sign with minor, tauri-bundler with minor, tauri-driver with minor Planned Package VersionsThe following package releases are the planned based on the context of changes in this pull request.
Add another change file through the GitHub UI by following this link. Read about change files or the docs at github.com/jbolda/covector |
2 participants
Closes #15170
WryHandle(the app/AppHandle-level runtime handle) implementedprimary_monitor,monitor_from_pointandavailable_monitorsby readingself.context.main_thread.window_targetdirectly on the calling thread. The taoEventLoopWindowTargetis not thread safe (GTK on Linux, Win32 on Windows), so calling these from a background thread races with the UI thread — the reporter seesAborted (core dumped),Segmentation fault, andmalloc(): unaligned fastbin chunkwithin seconds.cursor_positionon the same handle already avoids this by marshalling through the event loop. This routes the three monitor queries the same way, via newEventLoopWindowTargetMessagevariants handled on the main thread.send_user_messageruns inline when already on the main thread, so no deadlock and no behavior change for main-thread callers.The main-thread
Runtimeimpl keeps its direct access — it already runs on the UI thread.No repro on my machine (crash is Linux/Windows only), but the fix removes the off-thread
window_targetaccess that is the documented cause, mirroring the existingcursor_positionpath.