GRIN/android-activity
1
0
Fork 0
mirror of https://github.com/rust-mobile/android-activity.git synced 2026-07-13 18:18:56 +00:00
Code Issues Packages Projects Releases Wiki Activity

game-activity/README: refer to issue that describes ndk-glue sync concerns

Browse Source
This commit is contained in:
Robert Bragg
2022-05-20 01:48:45 +01:00
parent 3349344339
commit 57dda66a54
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
game-activity/README.md
+1 -1
View File
@@ -116,7 +116,7 @@ One of the appeals (imho) of the AGDK project was that they are maintaining nati
This crate uses the upstream glue layer written in C/C++ and provides a small Rust API on top for ergonomics. This way it's hopefully practical to keep in sync with upstream changes and bug fixes and to benefit from upstream testing.
The C/C++ GameActivity / android_native_app_glue code isn't _that_ complex and could well be re-implemented in Rust at some point, although it's not clear how beneficial it would be. I would note that `ndk-glue` did go down the route of re-implementing the glue layer for `NativeActivity` purely in Rust but I wasn't confident about it's synchronization model is correct which imho highlights that the code should only be re-written if there are some clear technical benefits. I'll try to follow up with Github issues to discuss more but for example it looks like `ndk-glue` has race conditions with its approach to synchronizing events (like window termination) by relying on a mutex write lock to block after issuing an (async) mainloop `wake()` up, relying on a documented convention that the application should take a read lock to block that write lock (which looks likely to have already been taken before the wakeup). I might be mistaken but the original C code seemed better designed in this regard because it could surround event handlers with pre/post processing that would reliably handle synchronization without the application being responsible for anything.
The C/C++ GameActivity / android_native_app_glue code isn't _that_ complex and could well be re-implemented in Rust at some point, although it's not clear how beneficial it would be. I would note that `ndk-glue` did go down the route of re-implementing the glue layer for `NativeActivity` purely in Rust but I wasn't confident about it's synchronization model is correct which imho highlights that the code should only be re-written if there are some clear technical benefits. (See here for more discussion: https://github.com/rust-windowing/winit/issues/2293)
# Synchronizing with Upstream...