Re: Binding and multithreading
Re: Binding and multithreading
- Subject: Re: Binding and multithreading
- From: Jens Alfke <email@hidden>
- Date: Sat, 24 Mar 2012 08:47:05 -0700
On Mar 24, 2012, at 2:46 AM, Jonathan Taylor wrote:
> It sounds, though, as if it should be ok to use observeValueForKeyPath:ofObject:change:context (which will run on the secondary thread, by the sound of it) as a way of monitoring the fact that "something" has changed in the state of my object. I can then use that as a single place in which I schedule a GUI update via a shadow object on the main thread. Does that sound as if it would be ok?
Yes. The -observeValue… method will be called on whatever thread the property changed on; as long as the method does the scheduling in a thread-safe way, it’ll be fine. (For example, I believe calling -[NSView setNeedsDisplay:] is thread-safe.)
This doesn’t really help solve the OP’s issue — it’s very convenient to use bindings instead of direct observation, as you don’t have to write code; but this gives you no opportunity to reschedule onto the main thread. Maybe it would be possible to implement a generic proxy object that could be interposed, and relay the property-change notifications from one thread to another. I don’t think this would allow easy wiring up of bindings from IB, though.
—Jens
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden