Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hold on to Android NativeWindow lock to prevent races #1892
Hold on to Android NativeWindow lock to prevent races #1892
Changes from all commits
c04011d
cbeddb0
b079b26
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two calls remaining to
ndk_glue::native_window()
. IMO these should useself.native_window_lock
and panic if it wasNone
(implying it was called outside aResumed
-Suspended
"block") instead of trying to grab the window on their own regard.That might require some refactoring as
fn raw_window_handle()
only has access tostruct Window
which is currently empty, withEventLoopWindowTarget
supposedly tying them together. I'm not sure what the desired flow is here, the other platform implementations should be able to help out here.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried something like that first. My attempt ran into
RwLockReadGuard
being!Send
and I gave that approach up. Will give it another try though.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I came up with something. Let me know what you think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would have preferred to keep the entire thing in one place without two mutexes/locks. It looks like other backends like Wayland store modifyable data in
EventLoopWindowTarget
through aRefCell
:winit/src/platform_impl/linux/wayland/event_loop/mod.rs
Lines 50 to 51 in 86748fb
That's where I'd put
native_window_lock
instead. Perhaps in a similar*State
struct and/or with atype
alias because it is getting quite long 😅Maybe the winit-Android developers have a better overview of where to place (mutable) data shared between the
EventLoop
andWindow
; @msiglreith @dvc94ch?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer that too, but I assumed that
Window
needs to beSend
, which complicates things. I'll take another look at the other backends and see if I can glean anything more.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Desktop platforms seem to make sure
Window
isSend
and synchronize state with the event loop (?). It's not clear how important this is on Android, but if it is, then the fact that you can't putRwLockReadGuard
behind anArc<Mutex<T>>
becomes a problem.winit/src/platform_impl/linux/wayland/window/mod.rs
Line 46 in 86748fb
winit/src/platform_impl/linux/x11/window.rs
Line 105 in 86748fb
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MarijnS95 Still no idea how to solve this without extra synchronization. Some input from a maintainer might be useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately I have not had the time to look at any alternatives either, seems like wrapping our state (either the readlock or raw window handle) inside yet another mutex is the only option - given
Send
limits this might only be possible with the window handle which has to be unconditionally retrieved and stored like this PR does currently.It would have also been nice if the lock could be transposed to remove the
Option
(only want to hold the lock if it contains a valid window) but that is not possible either.