diff --git a/game-activity/README.md b/game-activity/README.md
index 8d979b6..7baf2fd 100755
--- a/game-activity/README.md
+++ b/game-activity/README.md
@@ -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...