The Kotlin/Native runtime includes a few different variations of Atomics. This means that you can change values inside a frozen state. These classes implement a special-case handling of states in the Kotlin/Native runtime. Kotlin/Native provides a set of Atomic classes that can be frozen while still supporting changes to the value they contain. There are various techniques that help you work around these restrictions, each with their own pros and cons: Whatever the reason, it will not always be feasible to constrain a mutable state to a single thread. Or maybe you simply don't want to go through the potentially costly exercise of redesigning existing code. However, in many other cases, you may need arbitrary thread access to a state, or you may have service objects that should be available to the entire application. States were mutable from multiple threads in JVM code, but they didn't need to be.
#SWIFT SHARE VARIABLE BETWEEN THREADS CODE#
In many cases, simply changing your approach to how you design your code will work fine, and you don't need concurrent mutability. The result of following these rules is that you can't change global states, and you can't change the same shared state from multiple threads. When it comes to working with iOS, Kotlin/Native's state and concurrency model has two simple rules.Ī mutable, non-frozen state is visible to only one thread at a time.Īn immutable, frozen state can be shared between threads. Check out Kotlin/Native memory management to learn about the new memory manager, which has been enabled by default since Kotlin 1.7.20. This page describes the features of the legacy memory manager.
0 kommentar(er)
