Marijn Suijten
Marijn Suijten
> [Mozilla's Rust-Android-Gradle](https://github.com/mozilla/rust-android-gradle) seems to be only concerned about building Rust code. It does not seem to do anything about the "interoperability (...) with the Android framework" part. Because there's...
> > we could even have a drop handler? > > probably not worth overdoing this It would be clean. Not everyone might use ndk_glue (though it is unlikely) and...
@dvc94ch `NATIVE_ACTIVITY` is not protected by any mutex, otherwise we'd have to lock this for writing. https://github.com/rust-windowing/android-ndk-rs/blob/49e8ed51220567dccac9fd1e8baa526e9cdac163/ndk-glue/src/lib.rs#L56
Only the other bits: https://github.com/rust-windowing/android-ndk-rs/blob/49e8ed51220567dccac9fd1e8baa526e9cdac163/ndk-glue/src/lib.rs#L49-L54
It's probably not behind a lock because it's always "statically" set during activity execution and doesn't change (well, except when someone returns from `fn main()` while still having a thread...
> but it could panic right? > > https://github.com/rust-windowing/android-ndk-rs/blob/49e8ed51220567dccac9fd1e8baa526e9cdac163/ndk-glue/src/lib.rs#L59 Yes, but only if the user calls `native_activity()` after returning from `main()`, which we can simply deem invalid and incorrect.
> I think the `static mut` is only safe because it is initialized at startup and never written to Exactly. I think we might change `unwrap()` to `.expect("Native activity has...
Reading or writing the pointers is only a single instruction. The point is to prevent other threads doing so while the thread holding the lock is doing different things with...
> So what I'm saying is the program does this: > > 1. make static mut NATIVE_ACTIVITY None > 2. anything could happen including calling `native_activity` > 3. the drop...