Wednesday, August 26, 2020

Improved KVO in Big Sur

macOS Big Sur 11 beta 5:

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 where removeObserver(_:) is needed.

The improved determinism also allows improved Swift API handling. Instances of NSKeyValueObservation, produced by the Swift NSObject.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.


Sören, not necessarily, it could have been baking for months now.


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.

Leave a Comment