Correct, that is true for any language where you deal with raw threads, managed or unmanaged. That tells us that we should avoid using raw threads and instead use some other API to achieve parallelism.
Yes, exactly.
https://kkimdev.github.io/posts/2019/04/22/Rust-Compile-Time...
Of course, you can bypass this by using 'unsafe' code, where you are explicitly telling the compiler that you have manually verified Rust's safety guarantees.
This is why a significant portion of Rust's community gets agitated with (possibly unnecessary) use of 'unsafe' in popular libraries.
Considering many of the software problems we face have some connection to thread-safety, Rust is the way to go.
Threading seemed a good idea that went wrong.
Then you are back into the same synchronization issues as in every other language.
I'm trying to learn Android and some libraries give zero indication of what thread your callbacks will be called on.
Maybe there's a convention somewhere that says "On Android, you can't assume anything about callbacks, so always assume you're on some anonymous worker thread and lock everything or dispatch to a thread you own"
But I have not come across it yet.
You cannot assume anything about process or thread lifetimes on Android, as the simple act of rotating the screen will restart your application, and it can be killed at any moment and restarted later, due to memory pressure, or because the use has switched applications.
So whatever was the state of your application can be completely different when the callback is supposed to be invoked later on.