Search code examples
multithreadingcocoakey-value-observingcocoa-bindings

Is it safe to use Interface Builder bindings to observe properties changed on non-main thread?

If I use Interface Builder to bind, e.g. NSTextField's value to someObject.property and this property (assuming it's assign, atomic type) will change from a non-main thread, will this be safe/correct?

Cocoa generally forbids updating UI from non-main thread, so I wonder whether the binding mechanism automagically schedules updates to happen on the main thread for me, or is it unsafe to bind directly to objects that may be changed from other threads.

Does the same hold true if I fire KVO notifications myself?

-(void)setProperty: {
    dispatch_async(dispatch_get_global_queue(0,0), ^{
        [self willChangeValueForKey:@"property"];
        …
        [self didChangeValueForKey:@"property"];
    });
}

will the NSTextField observing that property still update itself on the main thread?

(related to problems I'm seeing with waitUntilExit)

Solution

  • It is not safe. Neither KVO nor Bindings redirects things to the main thread. If you change an observed property on a background thread, the observer is notified on that background thread. If the observer's response to the change notification is to update UI, then you've got a problem.