Improved KVO in Big Sur
Key-Value Observation removal facilities now employ deterministic bookkeeping methods. Cases that would have produced hard-to-diagnose crashes, especially those where KVO signals problems accessing deallocated observer pointers or observers associated with incorrect objects, now produce an exception pinpointing which observed object needs a missed
removeObserver(_:)
call, and by which observers. This exception was previously thrown as ‘best effort’ when KVO could detect the problem; the new deterministic bookkeeping allows it to be thrown for all cases whereremoveObserver(_:)
is needed.The improved determinism also allows improved Swift API handling. Instances of
NSKeyValueObservation
, produced by the SwiftNSObject.observe(_:changeHandler:)
method, take advantage of integration with this bookkeeping so they now invalidate automatically when the observed object is released, regardless of how the object implements its KVO behavior. This applies to all usage of this API in macOS 11 Big Sur beta, including on processes built with previous versions of the SDK, and eliminates certain classes of crashes that sometimes required using the legacy API instead.
Previously:
Update (2020-08-28): David Smith:
Tip re the
KVO_IS_RETAINING_ALL_OBSERVERS_OF_THIS_OBJECT_IF_IT_CRASHES_AN_OBSERVER_WAS_OVERRELEASED_OR_SMASHED
method that I added years ago: it really means all observers of that object, not just the ones being notified. Most of the time it’s an unrelated one you forgot about.(The reason is that determining which objects are being notified without introducing deadlocks requires dropping an internal lock, which would allow another thread to deallocate the observer out from under KVO, so it has to retain then figure out which are relevant)
6 Comments RSS · Twitter
Well, it’s about time. (“Finally!”)
Isn’t this how all expected/presumed that KVO should work from the very beginning?
I'm sure adding a feature like that, impacting virtually every application, in beta 5 isn't risky at all.
Oh, it probably has been baking for a while. But if it didn't ship in beta 1, that means beta 1 wasn't feature-complete, and that worries me.
@Sören They often add new stuff, particularly disruptive security-related stuff, months after the first beta. :(
Exactly. Or, y'know, messing up virtualization (and possibly other memory-heavy processes) in the sixth point release. https://mjtsai.com/blog/2020/07/28/macos-10-15-6-bug-causes-crashes-with-virtualization/
I understand bugs happen, but adding features late in a cycle makes them a fair bit more likely.