https://kotlinlang.org logo
Join Slack
Powered by
`StableRef` having object wrapping mutable proper...
# kotlin-native
a
StableRef
having object wrapping mutable property vs 
AtomicRef
? Which is better to store a mutable object not-frozen (sort of for thread isolation)?
Ah, I see, AtomicRef can only hold a frozen object, "It itself can be changed but its property is immutable/frozen"
d
StableRef isn't for thread isolation. You should use DetachedObjectGraph.
a
👀
I was reading through the docs (https://kotlinlang.org/docs/mobile/concurrent-mutability.html#atomics), and encountered that the library mentioned there (stately) was using StableRef to do so.
d
It'll work because the checks are missing but it would be considered naughty to do so. If you know what you're doing, go ahead.
👍 1
k
We use StableRef in a few places. You need to be careful, but I wouldn't say it's "wrong" per say.
👍 1
I also (probably) wouldn't use it directly outside of library code. Under the hood, that's how we're doing Isolate state. https://github.com/touchlab/Stately#stately-isolate
a
Thank you all, for the effort 😄
k
Yeah, I guess to clarify and rereading what @Dominaezzz said, you should definitely not touch StableRef if you aren't super familiar with the KN threading 🙂
a
Last question, does stableref leaks memory even if process is killed (and ref is not disposed)?
k
if process is killed
If the thread goes away, yes. You need to release the StableRef. If the process dies, you don't need to worry 🙂 (unless maybe you had some kind of external system resource?)
👍 1
☝️ 1
There has been discussion of some kind of deinit-like feature added, which would let you do things like close a StableRef, but that doesn't exist yet, and may never (but it would be pretty great).
a
Yeah, I like the concept of having class destructors in K/N 😅
d
k
I didn't know that either. Makes it easier, certainly. I've missed a bit of the 1.4 new stuff apparently
b
2 Views
Open in Slack
PreviousNext
Powered by