Rework Event type to allow synchronized cleanup #121
Closed
Conversation
This file contains 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
Previously, NativeActivity callbacks returned immediately after dispatching an asynchronous Event to the user on a UNIX pipe. This made it impossible to handle destruction events (`onNativeWindowDestroyed`, `onInputQueueDestroyed`) in a manner conforming to the Android docs, which state that all cleanup must be completed *before* the callback returns, cf. https://developer.android.com/ndk/reference/struct/a-native-activity-callbacks#struct_a_native_activity_callbacks_1a6aaafbbfae4c0ac066b9d61ebb3ab97f Therefore, some method of blocking and then notifying the callback thread had to be introduced. In order to accomplish this, I wrote a simple wrapper on a lockless queue (`crossbeam_queue::SegQueue`) and an `eventfd` object, which allows sending arbitrary Rust objects to the user while notifying the Android `Looper` in a manner preserving the source of the notification. This in turn enabled a different semantics of the `Event` type. `Events` now transfer ownership of various Android handles (e.g. `NativeActivity`, `InputQueue`) to the user. The user is responsible for storing these handles. When a corresponding `*Destroyed` event is received, the user must ensure that they complete all cleanup before dropping the contained `EventSyncGuard` object and do not touch the relevant handle afterwards.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Previously,
NativeActivitycallbacks returned immediately after dispatching an asynchronousEventto the user on a UNIX pipe. This made it impossible to handle destruction callbacks (on_native_window_destroyed,on_input_queue_destroyed) in a manner conforming with the Android docs, which state that all cleanup must be completed before the callback returns, cf.ANativeActivityCallbacks docs.Therefore, some method of blocking and then notifying the callback had to be introduced. In order to accomplish this, I wrote a simple wrapper on a lockless queue (
crossbeam_queue::SegQueue) and aneventfdobject, which allows sending arbitrary Rust objects to the user while notifying the AndroidLooperin a manner preserving the source of the notification.This enabled a different semantics of the
Eventtype.Eventsnow transfer ownership of various Android handles (e.g.NativeActivity,InputQueue) to the user. The user is responsible for hanging on to these handles. When a corresponding*Destroyedevent is received, the user must ensure that they complete all cleanup before dropping the containedEventSyncGuardobject. They must not touch the relevant handle afterwards.Additionally, care is taken to prevent the user from obtaining a handle to a
NativeWindowor anInputQueueafter a corresponding*_destroyedcallback has fired. In this case, the*Createdevent will deliverNoneand no corresponding*Destroyedevent will be dispatched.This is a somewhat significant change of the public API and there are ways to make it more similar to the current version or just more ergonomic. I'm open to discussing these, as well as any performance or synchronization concerns.