fix(runtime-wry)!: query monitors on main thread from runtime handle - #15630
Conversation
|
@FabianLars done in fc2078b — switched all three ( One wrinkle: the macro expands to Reads cleaner for |
|
Ah shit i didn't see the |
|
@FabianLars done in a989173 (revert in 57bd57c) — no worries on the back-and-forth. Back to the explicit |
Package Changes Through cd7a619There are 14 changes which include tauri with minor, tauri-cli with minor, @tauri-apps/cli with minor, tauri-runtime with minor, tauri-runtime-wry with minor, tauri-utils with minor, tauri-bundler with minor, tauri-build with minor, tauri-macos-sign with minor, tauri-codegen with minor, tauri-macros with minor, tauri-plugin with minor, tauri-driver with minor, @tauri-apps/api 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 |
|
Please sign your commits. |
a989173 to
09bf1e6
Compare
|
@Legend-Master done — re-signed all four commits with SSH and force-pushed, they're showing Verified now. Also rebased onto latest |
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 `?`.
…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.
09bf1e6 to
50bd1a8
Compare
833169a to
6f03948
Compare
Legend-Master
changed the title
|
@FabianLars Since the runtime and runtime-wry crates are not stable, I have gone ahead made them return results. I think this should be fine since the only consumer of the runtime crates is tauri and the implementers of the runtime crate need updates in respond to the added functions we do in minor functions anyways. Let me know your takes on this. |
this can always cause issues if packages are updated independently but since i've been pushing breaking changes for tauri-utils i can't complain about that here 😂 so lgtm |
|
I'm thinking to depend on minor versions after we get #15412 in for tauri |
3 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.