Speaking of the above :point_up_2: , I'm clearly m...
# ios
d
Speaking of the above 👆 , I'm clearly missing another of the peculiarities of the K/N Memory Model... Getting the dreaded:
Caused by: kotlin.native.concurrent.InvalidMutabilityException: mutation attempt of frozen kotlin.collections.HashMap@33944e8
...while adding an element to a
MutableSet
. However: • The Set is created while on the main thread • The Set is only ever accessed from the main thread (I've asserted these points with checks on
NSThread.isMainThread
at every relevant point) • The top level object under which the Set (indirectly) resides, is marked
@ThreadLocal
...which other restriction am I missing!? Is there a way to determine at what point an object is being frozen?
t
you can call
ensureNeverFrozen
after creating it, and then get an exception when something tries to freeze it
👍 2
d
Manna from heaven, thanks!
👍 1
...alright, so it turns out the freeze was because my Map was being transitively referenced as part of another
object
that wasn't
@ThreadLocal
.
The documentation does, I suppose, say this is the case.
But I feel like it doesn't make clear enough that any object that is accessible via any part of the object graph beneath a top-level
object
will be frozen unless marked
@ThreadLocal
. Would it be reasonable for the docs to advise that applying
@ThreadLocal
should be considered a sensible 'default' for newcomers.
...or something of that nature.
r
Agree that docs could be better around all of this, but
@ThreadLocal
by default would have it's own set of confusion and drawbacks. Anytime you access it from a background thread, none of the state you've set in the main thread will be present, but it might not be obvious that something's wrong because nothing will throw.
d
@russhwolf Ah, I didn't mean to suggest
@ThreadLocal
be an actual language default; agree it could cause some serious confusion... but rather a suggested way to start for those wanting to avoid the potentially greater complications of object freezing.