Speaking of the above :point_up_2: , I'm clearly missing another of the peculiarities of the K/N Mem...

# ios

[darkmoon_uk]

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?

[Tijl]

you can call ensureNeverFrozen after creating it, and then get an exception when something tries to freeze it

[darkmoon_uk]

Manna from heaven, thanks!

[darkmoon_uk]

...alright, so it turns out the freeze was because my Map was being transitively referenced as part of another object that wasn't @ThreadLocal.

[darkmoon_uk]

The documentation does, I suppose, say this is the case.

[darkmoon_uk]

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.

[darkmoon_uk]

...or something of that nature.

[russhwolf]

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.

[darkmoon_uk]

@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.