Hello everyone, Since Multithreaded coroutines a thing now, do we need to use stately (or freeze state in general)? Documentation points against it, says The concurrency libraries mentioned here will freeze your data automatically. I'm using KaMPKit to get used to things, even if it uses multithreaded coroutines, stately is also used. So I'm really confused 😕 some concurrency concepts are hard for me to understand, should I really dive into those and try to learn as a KMM beginner?

You don’t need Stately do use multithreaded coroutines in Kotlin Multiplatform. You will need to get a good grasp on the concurrency model of Kotlin/Native, of which the tricky part essentially is:

Given multiple threads, when an object (instance of a class) is referenced from code executing on another thread from what it was created on, that object will automatically become frozen. A frozen object is immutable and thus can no longer be mutated (e.g. calling

.add()

on a

MutableList<T>

, or setting a property on the object) for the lifetime of the process/application, nor can any objects referenced by the frozen object, as those too will become frozen. Attempting to mutate a frozen object will throw an exception.

As to whether you need to dive into them and learn as a KMM beginner - it depends on the type of application you’re looking to build while learning 🙂

It wasn't that hard actually, thank you 🙂 so my question is, will

native-mt

branch of coroutines prevent the exception? or should I use

ensureNeverFrozen

to be sure about the freeze state?

The

native-mt

branch does not prevent freezing of objects by itself, nor does it prevent the exception when attempting to mutate a frozen object. You don’t need

ensureNeverFrozen()

(my team doesn’t use it at all). If your object is frozen (as the result of it being referenced by code executing on another thread), an exception will be thrown as soon as any part of your code attempts to mutate it, though any and all threads are allowed to read it at any given time. If you do need mutable shared state you can use an

AtomicReference

(e.g. from Stately), but you could also use some kind of event/message queue (e.g. the Main dispatcher) for all reads and writes of the state, effectively limiting all access to the state to a single thread.

thank you all 🙂 I wish @kpgalligan also made a comment, since he brought me here with his great Stranger Threads articles 🙂

The memory model update won't be until well into next year, I would guess. You don't need stately for anything, but there are multiple modules available. We're using "stately-common" in KaMP Kit, which is just a bunch of concurrency related definitions for common code. While you don't need

ensureNeverFrozen

, you definitely need to understand it, or you'll have a crap time debugging issues later. We use it for "View Model" level state in common code, as we're very intentional about what is and is not frozen.

If your object is frozen (as the result of it being referenced by code executing on another thread), an exception will be thrown as soon as any part of your code attempts to mutate it,

True. What you don't know (in complex cases) is how it was frozen, and when, which you need to know to debug the problem. That's what

ensureNeverFrozen

is for. You can just add that when debugging, but we use it on certain classes all the time, to ensure it's doing what we expect as development continues, especially with larger teams, or as devs new to KMP are contributing to the project. I will mistakenly freeze objects sometimes too, though. It's it easy to do by mistake.