Does freezing typically occur only when objects are passed across thread boundaries? Or are there ot...

# ios

[Iain Merrick]

Does freezing typically occur only when objects are passed across thread boundaries? Or are there other cases?

[ribesg]

Thread boundaries, top level stuff, and manual call to freeze(). I think that's all

[rudolf.hladik]

mind that, some libraries may freeze arguments you pass to them and that may freeze some of your classes as they may work on different threads, also return values are typically frozen

[ribesg]

I once had a bug where everything froze because I was passing some data class containing a list of items to another thread and I accidentally put an actual list I was using in there instead of a copy of the actual list… It’s often unclear.

I basically have ensureNeverFrozen() calls in all constructors of everything in my model layer now (repositories and services)

[Iain Merrick]

Having spent a few days evaluating this, I'm going to hold off on Kotlin Native until the new memory model is ready.

[Iain Merrick]

This probably won't be news to anyone here, but I think the current model has several problems that compound with each other:

[Iain Merrick]

• it's too easy to freeze objects accidentally — it seems like many things that would cause memory leaks in other systems can lead to a runtime crash here
• freezing is entirely runtime behaviour with no compile-time safety checks
• Android and JVM don't have freezing so things can work fine there but show unique bugs on native

[Iain Merrick]

I'd use single-threaded if I could, but I don't think I can as the code I wanted to share between Android and iOS uses KTOR