Notify event pipe before releasing NativeActivity resources#134
Merged
dvc94ch merged 1 commit intorust-mobile:masterfrom Mar 24, 2021
Merged
Conversation
MarijnS95
reviewed
Mar 21, 2021
Member
|
To be ever so slightly more specific, could you mention in the commit message that acquiring a writelock in step |
c9b8754 to
0a4eba8
Compare
8 tasks
maciejgodek
added a commit
to maciejgodek/winit
that referenced
this pull request
Mar 23, 2021
In order to ensure validity of the raw pointers to Android's `ANativeWindow` handed out by `Window::raw_window_handle()`, the `EventLoop` will hold on to a read lock on the `NativeWindow` returned by `ndk_glue::native_window()` between receiving the `WindowCreated` event and the matching `WindowDestroyed` event from `ndk-glue`'s event pipe. Note that this commit depends on recent fixes to `ndk-glue`, specifically this PR rust-mobile/ndk#134. Previous versions of `ndk-glue` will cause this code to deadlock due to a concurrency bug.
maciejgodek
added a commit
to maciejgodek/winit
that referenced
this pull request
Mar 23, 2021
In order to ensure validity of the raw pointers to Android's `ANativeWindow` handed out by `Window::raw_window_handle()`, the `EventLoop` will hold on to a read lock on the `NativeWindow` returned by `ndk_glue::native_window()` between receiving the `WindowCreated` event and the matching `WindowDestroyed` event from `ndk-glue`'s event pipe. Note that this commit depends on recent fixes to `ndk-glue`, specifically this PR rust-mobile/ndk#134. Previous versions of `ndk-glue` will cause this code to deadlock due to a concurrency bug.
0a4eba8 to
e1b6f86
Compare
The design of ndk-glue seems to imply that the user of a `NativeActivity` resource, e.g. `NativeWindow` obtained from `ndk_glue::native_window()`, should hold a read lock on the resource as long as they are using it. Therefore, ndk-glue's `NativeActivity` callbacks related to resource release should: (1) notify the user of upcoming resource release, (2) acquire a write lock on the handle, waiting for all read locks to be dropped, (3) drop the handle, (4) return from the callback. This allows the user to react and correctly release various objects derived from the resource (e.g. swapchains/surfaces from `NativeWindow`) before it goes away. Currently, the order is 2-3-1-4, which can lead to a deadlock (if the user holds on to a read guard) or a race condition (if they drop the read guard early). This commit fixes the order.
e1b6f86 to
47c7f1b
Compare
Contributor
Author
|
Ok, I think I fixed it. :) Apologies for the repeated force pushes, I can't focus today. |
MarijnS95
approved these changes
Mar 23, 2021
MarijnS95
added a commit
that referenced
this pull request
Aug 7, 2021
This completes #134 by applying the same pointer-equality check in `on_input_queue_destroyed` to `on_window_destroyed`, and documents when the user should hold on to or release any of the `RWLock`s to ensure proper lifetimes for dependencies like surfaces in graphics APIs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Currently, some
NativeActivitycallbacks (on_native_window_destroyed,on_input_queue_destroyed):(1) acquire a write lock on a static handle to the resource that is about to be destroyed, (2) drop the handle, (3) dispatch an asynchronous
Eventto the user on a UNIX pipe notifying of the release, (4) immediately return from the callback.This is incorrect according to
ANativeActivityCallbacks docs. If the user is holding on to a read lock on the handle (as they should), there will be a deadlock. If the user does not have a read lock on the handle, there is a race condition, since Android may free the resource before the user cleans up all the objects derived from that resource (e.g.EGLSurfacefromNativeWindow).In order to prevent races,
ndk_glueshould (1) notify users of upcoming resource release, so they can correctly clean up derived objects, and only then (2) acquire a write lock on the handle, (3) drop the handle, (4) return from the callback.Closes #117