What I’m really missing, while working with K/N’s ...

# kotlin-native

[KamilH]

What I’m really missing, while working with K/N’s memory management, is some kind of tutorial or list of good practices or patterns how to solve common problems. Especially with coroutines library, because I think it’s a way most of us doing background job in KN. There are a lot of articles that are trying to explain concurrency topic and this is great. However at the end of the day when you are starting to work with it, you implement simple class that keeps state, state is getting accessed in background thread and you are getting InvalidMutabilityException. When I get this the only easy way to work around this was to use “AtomicReference”, but later I started thinking if it’s the best solution and it is really not obvious to answers.
Some questions, that it would be great to know answers to:
• How to implement simple in memory cache? With and without Map (with one value that is nullable and with Map<V,K>)?
• How to implement a class that does something, keeps internal state, but we don’t know on what thread it is going to be used?
• For collections that keeps state, should we use IsoMutableList or MutableList<AtomicReference>? Will they work similarly? What are the performance implications?
• Is StateFlow useful when it’s about keeping a state?

[mbonnin]

IsoMutableList is certainly a better bet than MutableList<AtomicReference> . You might want to try a AtomicReference<MutableList> but that'd certainly require some locking to be really thread safe

[mbonnin]

Overall it's not easy... The Stately repo has a lot of great patterns.

[mbonnin]

I wrote a small memory cache a few days ago, largely inspired by Stately if that can help: https://github.com/apollographql/apollo-android/pull/2986

[KamilH]

Thank you your implementation looks very good.
I agree it’s not easy and that is why I’m a little bit disappointed, because K/N is here around for some time already and I hoped that there are going to emerge some “good practices” here and there, but that is still hard to find/figure out

[russhwolf]

It's particularly awkward right now because we know the memory model is going to be changing. So it's hard to invest a lot in libraries/tooling around the current memory model because we know it's going to go away.

[KamilH]

Sure I totally agree and I’m waiting eagerly for it. However we don’t even have kind of timeline about when it’s going to happen and KMM is advertised pretty strongly while some simple patterns are not yet standardize. I have wrote a library in KMM and I really love this piece of technology and I would like to promote it to others, but I’ve got a feeling that my knowledge in K/N concurrency is not strong enough to answer all of the questions about it when someone ask me

[napperley]

As it stands the current K/N memory model has three large restrictions that make event handling more difficult than it should be.

1. All event handlers must be top level functions (cannot use member level functions, or properties; no restriction with Kotlin JVM, and Kotlin JS)
2. Kotlin objects cannot be accessed in a event handler unless it is through a StableRef pointer (can easily leak memory if not managed properly; again Kotlin JVM and Kotlin JS don't have this restriction)
3. Mutable state cannot be captured in a event handler (very annoying since both Kotlin JVM, and Kotlin JS allow this)
Hopefully with the new memory model (GC based) all these restrictions will be removed. I think these restrictions are some of the reasons why not much work has gone into having KotlinX Coroutines support the Linux targets. Would likely change with the new Kotlin Native memory model.

[darkmoon_uk]

Currently in the throes of developing a production App around KMM: The K/N Memory Model is the biggest pain-point, either directly (mutability exceptions) or indirectly (no runBlockingTest)